POST!

A serialized object makes a round trip in a POST verb action in the ASP.NET Web API from client to server to client again:

1. The client will send a request to the server by way of the API that will contain an object to create.
   
    
2. The POST method in the ASP.NET Web API will then create the object at the server and then ultimately send it back to the client reshaped.
   
    
3. Everyone is happy!
   
    

This does not happen with DELETE in which one specifies an object to axe. One gets nothing back (ideally per REST ideals) from a server when trigging a DELETE at the API from the client. In PUT one also sends in a serialized object in the name of making an update (ideally per REST ideals) but here too, nothing is returned back. The POST is different (ideally per REST ideals) however, and the same serialized object you hand into a POST gets deserialized, tweaked, reserialized, and sent back to you! Why so? Isn't that silly? Well, the object that comes back to the client can have some bonus material that it might not have had to begin with. Something it may have learned in its travels is the unique id in the form of an integer (or a little less likely a Guid) that identifies it at the database. Anything else that must be calculated at the server may then decorate the newer, better thing that returns. The image at the right shows the process in terms of JSON serialization. It is from the book I have started reading on ASP.NET Web API which specifically is: Pro ASP.NET Web API Security: Securing ASP.NET Web API by Badrinarayanan Lakshmiraghavan. Note that if you hand in JSON you will, by default, get JSON back and if you hand in XML you will, by default, get XML back. Decorating the request shown here with an extra line reading...

Accept: application/xml

...will allow for XML to be handed back even though we are handing JSON in. The Accept value may be a list of comma separated items in lieu of one in particular. The ASP.NET Web API will honor the first MIME type it may make sense of in the list and if it can't make sense of any of them then it will be as if the Accept condition was never specified. One of the things which could come back decorating the new object is a set of Hypermedia links which denote what one may do with the object and how to drill down into more functionality yet. This sort of thing is part of the formal REST spec as suggested by Roy T. Fielding. That said, you are really a stickler for Roy if you feel the need to be that loyal. Most people fudge REST.