I have a WebApi project based on OWIN, and I wanted to extend the result of WebApi call with some additional data, for example add localization data to response.
Initial idea was to inject that logic in a pipeline and once we get a result of API call I just have wrap that json with wrapper that will contain translation and some additional properties like time of execution.
So I wrote my own middleware put it after UseWebApi() but it's not executed because WebApi doesn't call "Next" in case it handles the request
So the question is:
How can I modify/extend Json returned by WebApi middleware?
Any other ideas how to handle such a problem with an action that has to be executed for all requests?
Thanks
Regarding the middleware:
you need to place your middleware before UseWebApi, and put your logic after invoking the next middleware; in this case your code well execute after Web API is done processing the request.
You might also want to check the following blog post, it discusses the same scenario of yours:
http://www.devtrends.co.uk/blog/wrapping-asp.net-web-api-responses-for-consistency-and-to-provide-additional-information
Related
I have a SOAP endpoint which processes XML requests by identifying the unmarshalled object and then using appropriate handlers. Now, I am trying to make a new endpoint and handler method which would handle the same request differently. From what I understand, Spring-Webservices (or SOAP for that matter) doesn't have a RESTful-kind of routing for requests.
Can I route a SOAP request through two different endpoints with a URL suffix or something in the API path (kind-of RESTful) ? The namespace, localpart, etc all being same. If not, is there a way ?
SO doesn't seem to have working answers on this topic, tried this:
How can i have two separate web services with identical name space and local name requests be routed to different end points?
Multiple SOAP endpoints with one namespace & localpart
Any approach/ideas are appreciated.
As far as I understood, you need to execute different business logic methods depending on the flag value. Well, the most straightforward approach is to use an if statement directly inside the endpoint. If you want to call different API (controllers) methods, you can take a look at Spring Functional Endpoints. Though I'm not sure they are integrated with SOAP
The mentioned approaches in the question didn't work for me, so I used a mixed approach - made a RESTful api for the new endpoint with a different suffix in the url. I read the payload as a string and used marshallers to validate.
I have a general REST API (developed using Spring MVC) that takes a list of API requests as its request body.
Each API request in the list has its own URL and request body.
In the implementation of this general REST API, I need to call the corresponding Spring controller method (in the same app) for each of these individual API requests (with their appropriate URL and request body).
(I will then merge all those individual API responses and return it in one big response from the general REST API).
I've been searching around, but I'm unclear how to programmatically call Spring to execute each individual API request. I would ideally like to get back the ResponseEntity from each call instead of the actual JSON response.
(More information:
On the same app server as the general API, I need to translate the URL and JSON request body for each individual API into the arguments to the controller method. I also need to take the URL and have Spring determine which controller method to invoke itself.)
Any help would be greatly appreciated.
Thanks,
Matt
Answer depend on whether the individual URLs that you are planning to invoke is with in the same server (Accessible without using network call) or not
If it is with in the same app server, spawn multiple threads and invoke the individual methods and join the response together and send it back
If it is not within the same app server, there are many Async Restclients are there besides spring's own webclient/restTemplate etc
I am developing a Laravel application and using a Service layer pattern to isolate business logic. What I come across in all tutors/articles is passing the HTTP request object from the controller directly into the service. To me, it goes against the principle of a service being an API-independent piece of code that has a single responsibility for a certain functionality. Imagine I would like to call the service from the command line or from an event handler, I would then have to construct an HTTP Request object to pass to the controller.
Same goes for validation: as far as I understand, the validator would on failure either redirect the user back (which may have no sense in the case of command line or event handler) or return an HTTP error.
On the other hand, with a lot of form fields, there should be some structure to pass the data in, and the form itself already gives such structure.
What are best practices regarding this?
I've got a .NET WebApi solution. I'm constraining access to HTTPS but conditionally allowing HTTP traffic. One of the conditions is that all HTTP requests must use the HTTP POST method, passing the x-http-method-override header to supply the intended method so the request can be properly routed. I've configured a global DelegatingHandler to validate all incoming requests and perform the redirection if needed.
With standard routing everything works great. When I configure AttributeRouting things go off the rails. It appears that AttributeRouting attempts to locate the route before the DelegatingHandler modifies the request, resulting in improper routes or IIS 404 errors. Is there a way to intercept the route before the AttributeRouting handler resolves the route?
More info: The project is hosted on IIS (not self hosted). The AttributeRouting I'm using is what comes in WebApi 2.0. The DelegatingHandler is defined thusly in App_Start:
GlobalConfiguration.Configuration.MessageHandlers
.Add(new MyCustomDelegateHandler());
AttributeRouting is configured simply using:
GlobalConfiguration.Configuration.MapHttpAttributeRoutes();
The routes are defined using the attributes:
[HttpGet("api/test/v1/users")]
Couple of question for clarity...Is this a Selfhost or Webhost(IIS) scenario? By AttributeRouting you mean the built-in Web API 2 attribute routing and not TimMcCall's attribute routing nuget package...right?
There have always been differences between when route matching occurs between Selfhost and Webhost. In Selfhost, route matching happens after message handlers are run, where as in case of Webhost route matching happens before message handlers are run.
If your scenario is Webhost, then I would expect the behavior to not change...but if your are seeing different behavior, then can you share how your route configuration (WebApiConfig.cs & the attributed controller/action) look like?
In Webhost, to intercept requests before route matching happens, you could create a Owin middleware which sits before the request is received by Web API. In this middleware you can modify the request details as you need.
NOTE:
Based on the update "More Info" in the post above, pre-RTM bits were being used where this seems to be an issue and this is not longer a problem with the final RTM bits.
In my application there is a client and a WCf REST service. For invoking some wcf service the client is doing an http POST even though the service is a GET.
i do not want to do any changes in the client or the service.
So is there a way where i can convert this POST request to GET and add the data coming in as the POST to the URL and invoke the REST service.
Thanks in advance.
You can use URL Rewrite to issue 3xx Redirect which will use GET method, but you will loose all POST data.
The only safe way known to me is to rewrite POST request to some another custom page, where you:
collect all POST data/variables;
convert them into GET variables (assemble proper GET request);
issue 301 (or 302) Redirect to the proper URL (it will have all POST data sent as GET variables).
Such rewrite to custom page should be easy -- you need to check what method is used (POST or GET) and only invoke it on POST. The rest will be handled in that post-to-get script.
The reason for all of this complexity is the difference in how POST and GET requests work: with GET all data is sent as part of URL while POST uses request body to transfer variable's data.