There was a debate with one of the platform engineers (as a mobile dev), about the codes being returned.
The scenario is: when trying to create a resource the server is returning a 201 with the resource_id in the header. I would have expected a 201 response with a JSON body with the resource_id. In my opinion, this would be easier for the mobile clients to parse.
Am I wrong in thinking this way? Should I be really parsing headers?
Looking at RFC2616, in the section about the 201 Created response code, we find:
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.
So, putting that resource identifier in a Location header field is perfectly legitimate. But, reading further, we find:
The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field.
In other words, the server should provide the new resource location as part of the body of the response, formatted according to the requested content type.
For update, you shouldn't need to parse anything other than the Status Code. The updated content comes from the client so only the server needs to do the updating which after it finished it should just return 204 (No Content).
create and not update. Got confused. Sorry.