Tworzenie mikro-usług w .NET 6 - 3 pytania i odpowiedzi ze szkolenia (grudzień 2021)

Seria pytań uczestników, które pojawiły się podczas szkolenia Tworzenie mikro-usług w .NET 6 realizowanego w dniach 29.11-03.12.2021 r.


W jaki sposób przekierować przychodzące żądanie? np. / pod /hangfire

Wystarczy podpiąć mapowanie z wywołać przekierowanie:


 
app.UseEndpoints(endpoints =>
{
  endpoints.MapGet("/", async context => context.Response.Redirect("hangfire"));
}
Dla większej czytelności i wygody można utworzyć własną metodę rozszerzającą:

public static class EndpointExtensions
    {
        public static IEndpointRouteBuilder Redirect(
            this IEndpointRouteBuilder endpoints,
            string from, string to)
        {
            return Redirect(endpoints,
                new Redirective(from, to));
        }

        public static IEndpointRouteBuilder RedirectPermanent(
            this IEndpointRouteBuilder endpoints,
            string from, string to)
        {
            return Redirect(endpoints,
                new Redirective(from, to, true));
        }

        public static IEndpointRouteBuilder Redirect(
            this IEndpointRouteBuilder endpoints,
            params Redirective[] paths
        )
        {
            foreach (var (from, to, permanent) in paths)
            {
                endpoints.MapGet(from, async http => { http.Response.Redirect(to, permanent); });
            }

            return endpoints;
        }
    }

    public record Redirective(string From, string To, bool Permanent = false);
 
na podst. https://khalidabuhakmeh.com/simple-redirects-with-aspnet-core-endpoint-routing

W jaki sposób dodać własny nagłówek do odpowiedzi?

Zalecany sposób to podpięcie delegata pod metodę OnStarting()



app.Use(async (context, next) =>
{
    context.Response.OnStarting(() =>
    {
        context.Response.Headers.Add("X-MyHeader", "value1");
        return Task.CompletedTask;
    });
   
    await next();
   
});

 
Wskazany delegat zostanie wywołany przed wysłaniem odpowiedzi do klienta.

Czym się różni application/json-patch+json od application/merge-patch+json?

Jeden i drugi protokół są do siebie bardzo podobne i służą do tego samego. Jednak działają nieco inaczej...

JSON Patch application/json-patch+json opisany przez RFC6902 przypomina transakcje bazy danych. Jest to zbiór operacji (zamień, dodaj, usuń, skopiuj), które mogą być przeprowadzone na dokumencie. Na przykład:

[
	{
		"op" : "replace" ,
		"path" : "/email" ,
		"value" : "john.smith@domain.com"
	},

	{
		"op" : "remove" ,
		"path" : "/twitter" 
	}
]
JSON Merge Patch

application/merge-patch+json opisany przez RFC7386 zawiera docelową wersję dokumentu. Wartość null jest specjalnie traktowana i służy do usuwania elementów.

{
	"email": "john.smith@domain.com",
	"twitter": null
}
Jak widać format JSON Merge Patch jest dużo mniejszy i ma pierwszy rzut oka wydaje się lepszym rozwiązaniem. Niestety nie ma obsługi dodawania i usuwania elementów z kolekcji (array). Trudniejsze jest przechowywanie takiej operacji w bazie danych SQL. Chyba, że korzystamy z NoSQL, np. MongoDb

Dlatego format musimy wybrać zależnie od konkretnego przypadku. Jeśli wystarczy nam zmiana wartości to JSON Merge Patch może okazać się lepszym rozwiązaniem. Przy bardziej złożonych operacjach, np. dodawanie/usuwanie/powielanie elementów polecam JSON Patch.

Warto dodać, że w .NET Core 5 jest obsługa JSON Patch za pomocą standardowej paczki Microsoft.AspNetCore.JsonPatch. Natomiast JSON Merge Patch nie jest obsługiwany natomiast można skorzystać z paczki Morcatko.AspNetCore.JsonMergePatch

Polecam artykuł:
https://erosb.github.io/post/json-patch-vs-merge-patch/