I have an in-memory object graph accessible via ASP.NET WEB API 2. GET, POST, PUT, DELET code executes correctly except that the accessed collection is "untouched" when the next action methon is called. I use Fiddler to test and my own clients. Looks like the collection is reconstructed for every call.
I however need a single object graph that is accessed by all clients. Can Web API be configured to use singleton data, like WCF? Or do I have to make the data a singleton myself? I am testing in VS.2013, I don't have a dedicated OWIN host yet.
Create a message handler class that derives from DelegatingHandler.
Pass your graph into the constructor.
Add an instance of your handler to the config.MessageHandlers collection.
When a request passes through your message handler, add your graph to the properties collection of the request.
Create an extension method to make it easy to pull the graph out of the request object.
Make sure your graph is thread safe.
Related
I am learning Django Rest Framework and one of the things I have noticed is that Viewsets provide actions such as .list, .post instead of method handlers such as .get, .post which in turn are provided by Views. The documentation says that actions are more flexible than method handlers but I can't seem to find any reason for this. Could you please share some information on why does Viewsets use actions and not the method handlers?
request handlers like .get() and .post() are based on http request methods, while actions like .create() or .list() are from a functionality point of view. Suppose you have a view class that can return a single user's info by user id or return all users in sorted order. These two requests are all GET requests from the client side, but with different parameters and purposes. If you just want to use .get() handler in this case you will need to define two view functions and register the two urls in url config. Or you can use ViewSet class or generic view with mixins that has action functions .list() and .retrieve() to handle these requests, then using router class to set the url configs that follows the REST url standards.
GET and POST are the only HTTP methods to use when dealing with forms.
Django’s login form is returned using the POST method, in which the browser bundles up the form data, encodes it for transmission, sends it to the server, and then receives back its response.
GET, by contrast, bundles the submitted data into a string, and uses this to compose a URL. The URL contains the address where the data must be sent, as well as the data keys and values. You can see this in action if you do a search in the Django documentation, which will produce a URL of the form https://docs.djangoproject.com/search/?q=forms&release=1.
GET and POST are typically used for different purposes.
Any request that could be used to change the state of the system - for example, a request that makes changes in the database - should use POST. GET should be used only for requests that do not affect the state of the system.
GET would also be unsuitable for a password form, because the password would appear in the URL, and thus, also in browser history and server logs, all in plain text. Neither would it be suitable for large quantities of data, or for binary data, such as an image. A Web application that uses GET requests for admin forms is a security risk: it can be easy for an attacker to mimic a form’s request to gain access to sensitive parts of the system. POST, coupled with other protections like Django’s CSRF protection offers more control over access.
On the other hand, GET is suitable for things like a web search form, because the URLs that represent a GET request can easily be bookmarked, shared, or resubmitted.
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?
Since no one answered this question:
What issues to consider when rolling your own data-backend for Silverlight / AJAX on non-ASP.NET server?
Let me ask it another way:
How does WCF RIA Services handle authentication/authorization/security at a low level?
e.g. how does the application on the server determine that the incoming http request to change data is coming from a valid client and not from non-desirable source, e.g. a denial-of-service bot?
From my investigation, all calls into the RIA service classes are forced through a custom IOperationInvoker class (enforced by a custom IOperationBehavior class). This invoker calls into DomainService to have the operation executed.
Before it is executed, the method call is validated any/all AuthorizationAttribute attributes marked on the operation in question. Each AuthorizationAttribute (two provided are RequiresAuthenticationAttribute & RequiresRoleAttribute) is given an opportunity to accept or reject the call via the abstract IsAuthorized method.
If any of these attributes returns something other than "AuthorizationResult.Allowed", an UnauthorizedAccessException exception is thrown with the ErrorMessage from the AuthorizationResult returned.
Recently I was working on web services proxy. I got 2 web services proxy. UI will call Proxy A to let say create a record. then what Proxy A will do is to call Proxy B to do the actual task which create the record (For some reason must go through Proxy A) now the problem is When UI call Proxy A, Proxy A will pass the objectA to Proxy B createRecord method which take in another different object type. Anyone came across this problem before can give me some suggestion. Instead of convert object A to object B.
Did you thought to use xsl in order to transform you ProxyA request into ProxyB request?
http://www.w3.org/Style/XSL/