Last post Sep 17, 2012 02:04 PM by GaryDean
Sep 16, 2012 08:18 PM|GaryDean|LINK
I have a bunch of WCF SOAP services that serve my WP7 apps. They do all sorts of things but basically they take arguments and return results. It all works well.
Now I'm porting those apps to Android and there I must deal with REST instead of SOAP. So I'm using asp.net web api. and I plan to duplicate my SOAP services using http to send and receive the same arguments and results.
I'm going through a tutorial entitled "Creating a Web API that Supports CRUD Operations". Here it's all about GET, PUT, POST, DELETE. Now I know those are the basic http verbs. For instance, the following is the definition from the tutorial explaining
"The four main HTTP methods (GET, PUT, POST, and DELTETE) can be mapped to CRUD operations as follows:
•GET retrieves the representation of the resource at a specified URI. GET should have no side effects on the server.
•PUT updates a resource at a specified URI. PUT can also be used to create a new resource at a specified URI, if the server allows clients to specify new URIs. For this tutorial, the API will not support creation through PUT.
•POST creates a new resource. The server assigns the URI for the new object and returns this URI as part of the response message.
•DELETE deletes a resource at a specified URI."
I understand that the word "Get" or "put" affects the routing to the correct method but once in the method my logic can do anything it wants - right? I could have a method named "PutProducts" that computes the square root of and integer and returns it -
it doesn't put anything.
As long as my service methods can accept any imaginable input arguments and return any imaginable output data, what does it matter if it's a GET, PUT, POST, or Delete?
I don't get it.
Sep 17, 2012 10:02 AM|panesofglass|LINK
The method name routing convention is useful for those abiding by the HTTP spec defined in
RFC2616. You are certainly free within a Web API application to do whatever you please, though if you expose your API for public consumption to 3rd parties, you will be breaking the contract defined
in that specification. The method name routing convention exists to make it easier to route your API calls. You can also use the [HttpPost]-style attributes and set the "action" parameter in your routes if you don't like or don't want those method names.
Also, those four HTTP methods are not the basic methods. Several others exist; those are just the ones most commonly linked to the classic CRUD-style application. They don't really align very well if you read the HTTP spec.
As to your last statement, "I don't get it," could you explain what exactly you don't understand? HTTP has a stated contract that is not easily enforcable. In fact, you can break that contract in many different ways, the most notorious of which is executing
delete actions over GET requests, once popular in ajax applications until search bots started "following the link" and deleting content.
I think it would be really nice to see a compile-time check that the HTTP methods were constrained appropriately, but then you would probably need a special language and compiler to perform that check. As it is, the conventions are useful, but you still
have to think about what you are doing. Freedom and flexibility are yours for the taking and the abuse. :)
Sep 17, 2012 02:04 PM|GaryDean|LINK
I just wanted to make sure that there are no enforced limitations as to what can be done in a method.
When I say "I don't get it" it's because, as we all know, the world is more complicated than GET, POST, etc. I will be violating the heck out of that RFC spec. I expect that everyone else who writes services for their own consumption will too. I'm just
surprised that the capability is presented in the light that it is being presented. WCF certainly never was.