{"id":369790,"date":"2024-05-21T04:11:12","date_gmt":"2024-05-21T04:11:12","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=369790"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-05-21T04:11:12","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=369790","title":{"rendered":"Validation of custom data with Minimal API filters, sensible and without fuss<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

I believe anyone would like to study new technologies \u201con the fly<\/em>\u201d. Any extra-efforts which may arise in comprehending some difficult subject may disgust that person and cause him or her to stop doing it. To me, it would seem kind of obvious why this is so.<\/p>\n

To be honest, I would like to be considering a bit about features which were presented in\u00a0ASP.NET<\/em>\u00a0starting from the 6th version and the possibilities that appeared after that in part of high-quality validation of custom data based on usage of the\u00a0Minimal API<\/em>\u00a0filters but I would not like getting too deep into that to keep the topic simple. Let\u2019s just focus on integration of the well-known package \u2018FlatValidator\u2019<\/em>\u00a0into a custom application.<\/p>\n

A little retrospect into the past. The\u00a0Minimal API<\/em>\u00a0was announced as a flexible software technique designed to serve\u00a0HTTP-routing<\/em>\u00a0in server-side applications. Previously, the architecture model of the controllers was used for development but the implementation of the\u00a0Minimal API<\/em>\u00a0has given some feeling the time of the controllers is inexorably running out.<\/p>\n

If you have heard nothing about all this, it does not matter because further discussion will bring some clarification, now I am just marking the boundaries of the issue that is currently being studied.<\/p>\n

Endpoint filters are known mainly within the framework of the\u00a0Minimal API<\/em>\u00a0technique, although they are also available for\u00a0MVC<\/em>\u00a0and\u00a0Razor Pages<\/em>. The filters look like a cross between the\u00a0endpoint request handler<\/em>\u00a0itself and\u00a0middleware<\/em>. The term \u2018middleware<\/em>\u2019 means a software module embedded into the\u00a0HTTP-request<\/em>\u00a0processing chain, the modules are executed sequentially, one after the other. Why am I mentioning this? Previously,\u00a0middlewares<\/em>\u00a0were often used for data validation. Now there is a more preferable method like an implementation of the\u00a0\u2018IEndpointFilter\u2019<\/em>\u00a0interface.<\/p>\n

The simplest implementation code for\u00a0\u2018IEndpointFilter\u2019<\/em>\u00a0may look like the codes below:<\/p>\n

public class MyFilter: IEndpointFilter  {     public async ValueTask<object?> InvokeAsync(         EndpointFilterInvocationContext context,         EndpointFilterDelegate next)     {               var result = await next(context);         if (result is string s)        {            result = s.Replace(\"vodka\", \"pineapple juice\");        }        return result;     } }<\/code><\/pre>\n
Let\u2019s explore what happens here. We execute the\u00a0next(\u2026)<\/em>\u00a0method which will call the endpoint handler and return a response with user data. Next step it replaces the fragment `vodka<\/em>` with the phrase `pineapple juice<\/em>\u2019 in the response. Everything is absolutely simple.<\/p>\n
In this example we add our custom processing after executing the\u00a0next(\u2026)\u00a0<\/em>method, such an approach is called post-processing. In case we do some processing before executing the next() method, it will be called pre-processing.<\/p>\n
Let\u2019s try to use implemented codes within the Minimal API<\/em> application.<\/p>\n
var builder = WebApplication.CreateBuilder(args);   var app = builder.Build();   var group = app     .MapGroup(string.Empty)     .AddEndpointFilter<MyFilter>();  \/\/ <==  group.MapGet(\"\/\", () => \"Hello World\");  group.MapGet(\"\/drinking\", () => \"I like to drink vodka!\");   app.Run();<\/code><\/pre>\n
Attempting to call the endpoint \u2018\/drinking\u2019 will lead to returning the phrase `I like to drink pineapple juice!<\/em>\u2019. Such a surprise for one who loves to drink vodka<\/em>.<\/p>\n
So, now the filters of the Minimal API<\/em> have been sorted out a bit, it is time to switch to a more real-life example. First of all, let\u2019s install the main\u00a0\u2018<\/em>FlatValidator<\/u><\/em><\/strong><\/a>\u2019<\/em>\u00a0package via\u00a0NuGet<\/u><\/em><\/strong><\/a>, it will help us to validate our data in a professional manner.<\/p>\n
\u276f dotnet add package FlatValidator<\/code><\/pre>\n
The documentation of the package page says the validator<\/em> is provided to be used in two approaches: inline and derived.<\/p>\n
Inline approach allows to define the validation rules at the verification point directly. It may be preferable for some cases and may give developers some advantages since they will be able to see the logic \u201cin place\u201d.<\/p>\n
On the other hand, if the project has some conceptual requirements regarding the isolation and structure convention of the business logic, it may be easier to use the classic approach with inheritance of the \u2018FlatValidator<TModel><\/em>\u2019 class.<\/p>\n
Let me show a slightly modified example from the documentation, the inline approach is used here:<\/p>\n
\/\/ use asynchronous version var result = await FlatValidator.ValidateAsync(model, v => {    \/\/ m == model, IsEmail() is one of funcs for typical data formats    v.ValidIf(m => m.Email.IsEmail(), \"Invalid email\", m => m.Email);     \/\/ involve custom userService for specific logic    v.ErrorIf(async m => await userService.IsUserExistAsync(m.Email),              \"User already registered\", m => m.Email); }); if (!result) \/\/ check the validation result {    return TypedResults.ValidationProblem(result.ToDictionary()); }<\/code><\/pre>\n
In fact, the \u2018ValidIf<\/em>\u2019 and \u2018ErrorIf<\/em>\u2019 functions are the validation rule definitions here. The number of such rules are not limited. The \u2018TypedResults.ValidationProblem<\/em>\u2019 is a part of\u00a0.NET 6+<\/em>, it will return error(s) in the\u00a0HTTP-response<\/em>\u00a0in case it occurs.<\/p>\n
The application code part in the concept of\u00a0inline-mode<\/em>\u00a0may look like this:<\/p>\n
var builder = WebApplication.CreateBuilder(args);  builder.Services.AddProblemDetails();  var app = builder.Build();   \/\/ Endpoint aka https:\/\/localhost:5000\/todos\/ app.MapPost(\"\/todos\", (Todo todo) => {    var result = FlatValidator.Validate(todo, v =>    {        v.ErrorIf(m => m.Title.IsEmpty(), \"Invalid title.\", m => m.Title);    });    if (!result)    {        return TypedResults.ValidationProblem(result.ToDictionary());    }     \/\/ ....    return Results.Ok(); });   app.Run();  \/\/ Model to test validation functionality public record Todo(string Title, bool IsComplete = false);<\/code><\/pre>\n
Pay attention, both\u00a0synchronous<\/em>\u00a0and\u00a0asynchronous<\/em>\u00a0versions are presented in the\u00a0FlatValidator<\/em>\u00a0class.<\/p>\n
If the\u00a0inline<\/em>\u00a0approach does not seem appropriate enough to you for some reason, you can derive the\u00a0FlatValidator<><\/em>\u00a0and create an independent class.<\/p>\n
var builder = WebApplication.CreateBuilder(args);  builder.Services.AddProblemDetails();  var app = builder.Build();   app.MapPost(\"\/todos\", (Todo todo) => {    var result = new TodoValidator().Validate(todo);    if (!result)    {        return TypedResults.ValidationProblem(result.ToDictionary());    }     \/\/ ....    return Results.Ok(); });   app.Run();  \/\/ Model to test validation functionality public record Todo(string Title, bool IsComplete = false);  \/\/ Implement custom validator for the model Todo public class TodoValidator : FlatValidator<Todo> {    public TodoValidator()    {        v.ErrorIf(m => m.Title.IsEmpty(), \"Invalid title.\", m => m.Title);    } }<\/code><\/pre>\n
For separated logic such definition manners may look neater. It is clear that the classes \u2018Todo\u2019<\/em>\u00a0and \u2018TodoValidator\u2019\u00a0<\/em>should each be in their own file.<\/p>\n
Well, now we have one step left before implementing a real validation filter. First of all, we have to write the logic of the validator<\/em> calling directly in the filter implementation.<\/p>\n
app.MapPost(\"\/todos\", (Todo todo) => {    return Results.Ok();  }).AddEndpointFilter<ValidationFilter<Todo>>();  \/\/ <==   public class ValidationFilter<T>(          IServiceProvider serviceProvider ) : IEndpointFilter {    public async ValueTask<object?> InvokeAsync(        EndpointFilterInvocationContext context,        EndpointFilterDelegate next)    {        var validators = serviceProvider.GetServices<IFlatValidator<T>>();        foreach (var validator in validators)        {            if (context.Arguments.FirstOrDefault(x =>                    x?.GetType() == typeof(T)) is not T model)            {                return TypedResults.Problem(                    detail: \"Invalid parameter.\",                    statusCode: StatusCodes.Status500InternalServerError                );            }             var result = await validator.ValidateAsync(model);            if (!result)            {              return TypedResults.ValidationProblem(result.ToDictionary());            }        }         \/\/ call next filter in the chain        return await next(context);    } }<\/code><\/pre>\n
Have you noticed? The body of the endpoint\u00a0.MapPost(\u201c\/todos\u201d)<\/em>\u00a0generally has been got rid of any logic related to validation at all! All logic is in the filter now.<\/p>\n
The validation is guaranteed by\u00a0.AddEndpointFilter<ValidationFilter<Todo>><\/em>.<\/p>\n
Since our filter is generic, it may be appropriate for any model type, so that it is enough to implement the class of the validator<\/em> and register it in the \u2018IServiceCollection<\/em>\u2019.<\/p>\n
\/\/ register a validator for the Todo model builder.Services.AddScoped<IFlatValidator<Todo>, TodoValidator>();<\/code><\/pre>\n
However, there are no problems with this either. If you would like to automate the registration of all your validators<\/em>, just use the small\u00a0NuGet<\/u><\/em><\/strong><\/a>\u00a0additional package\u00a0FlatValidator.DependencyInjection<\/u><\/em><\/strong><\/a>.  <\/p>\n
\u276f dotnet add package FlatValidator.DependencyInjection<\/code><\/pre>\n
It helps you to seek and register all validators<\/em> in the application.  <\/p>\n
var builder = WebApplication.CreateBuilder(args);  builder.Services.AddFlatValidatorsFromAssembly(Assembly.GetExecutingAssembly());<\/code><\/pre>\n
In general, to get better acquainted with the capabilities of the\u00a0\u2018<\/em>FlatValidator<\/u><\/em><\/strong><\/a>\u2019<\/em>\u00a0package, I recommend taking a look at the\u00a0project page<\/u><\/em><\/strong><\/a>, which contains documentation and some good examples.<\/p>\n
It\u2019s no secret that writing productive code is quite difficult. Often, it is no less difficult to read optimized codes later with understanding because final performance and code clarity are sometimes two completely different things. Nevertheless, the\u00a0\u2018<\/em>FlatValidator<\/u><\/em><\/strong><\/a>\u2019<\/em>\u00a0package managed to get fantastic performance with optimizing source codes but at the same time keeping these codes readable.<\/p>\n
And finally, a couple of words about performance. A picture below demonstrates the comparative performance and memory usage. The benchmarks themselves may also be found on the project page, may be downloaded and tested.<\/p>\n
<\/figure>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/797621\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
\n
\n
\n
\n
I believe anyone would like to study new technologies \u201con the fly<\/em>\u201d. Any extra-efforts which may arise in comprehending some difficult subject may disgust that person and cause him or her to stop doing it. To me, it would seem kind of obvious why this is so.<\/p>\n
To be honest, I would like to be considering a bit about features which were presented in\u00a0ASP.NET<\/em>\u00a0starting from the 6th version and the possibilities that appeared after that in part of high-quality validation of custom data based on usage of the\u00a0Minimal API<\/em>\u00a0filters but I would not like getting too deep into that to keep the topic simple. Let\u2019s just focus on integration of the well-known package \u2018FlatValidator\u2019<\/em>\u00a0into a custom application.<\/p>\n
A little retrospect into the past. The\u00a0Minimal API<\/em>\u00a0was announced as a flexible software technique designed to serve\u00a0HTTP-routing<\/em>\u00a0in server-side applications. Previously, the architecture model of the controllers was used for development but the implementation of the\u00a0Minimal API<\/em>\u00a0has given some feeling the time of the controllers is inexorably running out.<\/p>\n
If you have heard nothing about all this, it does not matter because further discussion will bring some clarification, now I am just marking the boundaries of the issue that is currently being studied.<\/p>\n
Endpoint filters are known mainly within the framework of the\u00a0Minimal API<\/em>\u00a0technique, although they are also available for\u00a0MVC<\/em>\u00a0and\u00a0Razor Pages<\/em>. The filters look like a cross between the\u00a0endpoint request handler<\/em>\u00a0itself and\u00a0middleware<\/em>. The term \u2018middleware<\/em>\u2019 means a software module embedded into the\u00a0HTTP-request<\/em>\u00a0processing chain, the modules are executed sequentially, one after the other. Why am I mentioning this? Previously,\u00a0middlewares<\/em>\u00a0were often used for data validation. Now there is a more preferable method like an implementation of the\u00a0\u2018IEndpointFilter\u2019<\/em>\u00a0interface.<\/p>\n
The simplest implementation code for\u00a0\u2018IEndpointFilter\u2019<\/em>\u00a0may look like the codes below:<\/p>\n
public class MyFilter: IEndpointFilter  {     public async ValueTask<object?> InvokeAsync(         EndpointFilterInvocationContext context,         EndpointFilterDelegate next)     {               var result = await next(context);         if (result is string s)        {            result = s.Replace(\"vodka\", \"pineapple juice\");        }        return result;     } }<\/code><\/pre>\n
Let\u2019s explore what happens here. We execute the\u00a0next(\u2026)<\/em>\u00a0method which will call the endpoint handler and return a response with user data. Next step it replaces the fragment `vodka<\/em>` with the phrase `pineapple juice<\/em>\u2019 in the response. Everything is absolutely simple.<\/p>\n
In this example we add our custom processing after executing the\u00a0next(\u2026)\u00a0<\/em>method, such an approach is called post-processing. In case we do some processing before executing the next() method, it will be called pre-processing.<\/p>\n
Let\u2019s try to use implemented codes within the Minimal API<\/em> application.<\/p>\n
var builder = WebApplication.CreateBuilder(args);   var app = builder.Build();   var group = app     .MapGroup(string.Empty)     .AddEndpointFilter<MyFilter>();  \/\/ <==  group.MapGet(\"\/\", () => \"Hello World\");  group.MapGet(\"\/drinking\", () => \"I like to drink vodka!\");   app.Run();<\/code><\/pre>\n
Attempting to call the endpoint \u2018\/drinking\u2019 will lead to returning the phrase `I like to drink pineapple juice!<\/em>\u2019. Such a surprise for one who loves to drink vodka<\/em>.<\/p>\n
So, now the filters of the Minimal API<\/em> have been sorted out a bit, it is time to switch to a more real-life example. First of all, let\u2019s install the main\u00a0\u2018<\/em>FlatValidator<\/u><\/em><\/strong><\/a>\u2019<\/em>\u00a0package via\u00a0NuGet<\/u><\/em><\/strong><\/a>, it will help us to validate our data in a professional manner.<\/p>\n
\u276f dotnet add package FlatValidator<\/code><\/pre>\n
The documentation of the package page says the validator<\/em> is provided to be used in two approaches: inline and derived.<\/p>\n
Inline approach allows to define the validation rules at the verification point directly. It may be preferable for some cases and may give developers some advantages since they will be able to see the logic \u201cin place\u201d.<\/p>\n
On the other hand, if the project has some conceptual requirements regarding the isolation and structure convention of the business logic, it may be easier to use the classic approach with inheritance of the \u2018FlatValidator<TModel><\/em>\u2019 class.<\/p>\n
Let me show a slightly modified example from the documentation, the inline approach is used here:<\/p>\n
\/\/ use asynchronous version var result = await FlatValidator.ValidateAsync(model, v => {    \/\/ m == model, IsEmail() is one of funcs for typical data formats    v.ValidIf(m => m.Email.IsEmail(), \"Invalid email\", m => m.Email);     \/\/ involve custom userService for specific logic    v.ErrorIf(async m => await userService.IsUserExistAsync(m.Email),              \"User already registered\", m => m.Email); }); if (!result) \/\/ check the validation result {    return TypedResults.ValidationProblem(result.ToDictionary()); }<\/code><\/pre>\n
In fact, the \u2018ValidIf<\/em>\u2019 and \u2018ErrorIf<\/em>\u2019 functions are the validation rule definitions here. The number of such rules are not limited. The \u2018TypedResults.ValidationProblem<\/em>\u2019 is a part of\u00a0.NET 6+<\/em>, it will return error(s) in the\u00a0HTTP-response<\/em>\u00a0in case it occurs.<\/p>\n
The application code part in the concept of\u00a0inline-mode<\/em>\u00a0may look like this:<\/p>\n
var builder = WebApplication.CreateBuilder(args);  builder.Services.AddProblemDetails();  var app = builder.Build();   \/\/ Endpoint aka https:\/\/localhost:5000\/todos\/ app.MapPost(\"\/todos\", (Todo todo) => {    var result = FlatValidator.Validate(todo, v =>    {        v.ErrorIf(m => m.Title.IsEmpty(), \"Invalid title.\", m => m.Title);    });    if (!result)    {        return TypedResults.ValidationProblem(result.ToDictionary());    }     \/\/ ....    return Results.Ok(); });   app.Run();  \/\/ Model to test validation functionality public record Todo(string Title, bool IsComplete = false);<\/code><\/pre>\n
Pay attention, both\u00a0synchronous<\/em>\u00a0and\u00a0asynchronous<\/em>\u00a0versions are presented in the\u00a0FlatValidator<\/em>\u00a0class.<\/p>\n
If the\u00a0inline<\/em>\u00a0approach does not seem appropriate enough to you for some reason, you can derive the\u00a0FlatValidator<><\/em>\u00a0and create an independent class.<\/p>\n
var builder = WebApplication.CreateBuilder(args);  builder.Services.AddProblemDetails();  var app = builder.Build();   app.MapPost(\"\/todos\", (Todo todo) => {    var result = new TodoValidator().Validate(todo);    if (!result)    {        return TypedResults.ValidationProblem(result.ToDictionary());    }     \/\/ ....    return Results.Ok(); });   app.Run();  \/\/ Model to test validation functionality public record Todo(string Title, bool IsComplete = false);  \/\/ Implement custom validator for the model Todo public class TodoValidator : FlatValidator<Todo> {    public TodoValidator()    {        v.ErrorIf(m => m.Title.IsEmpty(), \"Invalid title.\", m => m.Title);    } }<\/code><\/pre>\n
For separated logic such definition manners may look neater. It is clear that the classes \u2018Todo\u2019<\/em>\u00a0and \u2018TodoValidator\u2019\u00a0<\/em>should each be in their own file.<\/p>\n
Well, now we have one step left before implementing a real validation filter. First of all, we have to write the logic of the validator<\/em> calling directly in the filter implementation.<\/p>\n
app.MapPost(\"\/todos\", (Todo todo) => {    return Results.Ok();  }).AddEndpointFilter<ValidationFilter<Todo>>();  \/\/ <==   public class ValidationFilter<T>(          IServiceProvider serviceProvider ) : IEndpointFilter {    public async ValueTask<object?> InvokeAsync(        EndpointFilterInvocationContext context,        EndpointFilterDelegate next)    {        var validators = serviceProvider.GetServices<IFlatValidator<T>>();        foreach (var validator in validators)        {            if (context.Arguments.FirstOrDefault(x =>                    x?.GetType() == typeof(T)) is not T model)            {                return TypedResults.Problem(                    detail: \"Invalid parameter.\",                    statusCode: StatusCodes.Status500InternalServerError                );            }             var result = await validator.ValidateAsync(model);            if (!result)            {              return TypedResults.ValidationProblem(result.ToDictionary());            }        }         \/\/ call next filter in the chain        return await next(context);    } }<\/code><\/pre>\n
Have you noticed? The body of the endpoint\u00a0.MapPost(\u201c\/todos\u201d)<\/em>\u00a0generally has been got rid of any logic related to validation at all! All logic is in the filter now.<\/p>\n
The validation is guaranteed by\u00a0.AddEndpointFilter<ValidationFilter<Todo>><\/em>.<\/p>\n
Since our filter is generic, it may be appropriate for any model type, so that it is enough to implement the class of the validator<\/em> and register it in the \u2018IServiceCollection<\/em>\u2019.<\/p>\n
\/\/ register a validator for the Todo model builder.Services.AddScoped<IFlatValidator<Todo>, TodoValidator>();<\/code><\/pre>\n
However, there are no problems with this either. If you would like to automate the registration of all your validators<\/em>, just use the small\u00a0NuGet<\/u><\/em><\/strong><\/a>\u00a0additional package\u00a0FlatValidator.DependencyInjection<\/u><\/em><\/strong><\/a>.  <\/p>\n
\u276f dotnet add package FlatValidator.DependencyInjection<\/code><\/pre>\n
It helps you to seek and register all validators<\/em> in the application.  <\/p>\n
var builder = WebApplication.CreateBuilder(args);  builder.Services.AddFlatValidatorsFromAssembly(Assembly.GetExecutingAssembly());<\/code><\/pre>\n
In general, to get better acquainted with the capabilities of the\u00a0\u2018<\/em>FlatValidator<\/u><\/em><\/strong><\/a>\u2019<\/em>\u00a0package, I recommend taking a look at the\u00a0project page<\/u><\/em><\/strong><\/a>, which contains documentation and some good examples.<\/p>\n
It\u2019s no secret that writing productive code is quite difficult. Often, it is no less difficult to read optimized codes later with understanding because final performance and code clarity are sometimes two completely different things. Nevertheless, the\u00a0\u2018<\/em>FlatValidator<\/u><\/em><\/strong><\/a>\u2019<\/em>\u00a0package managed to get fantastic performance with optimizing source codes but at the same time keeping these codes readable.<\/p>\n
And finally, a couple of words about performance. A picture below demonstrates the comparative performance and memory usage. The benchmarks themselves may also be found on the project page, may be downloaded and tested.<\/p>\n
<\/figure>\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/797621\/<\/a>
<\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-369790","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/369790","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=369790"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/369790\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=369790"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=369790"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=369790"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}