C'è stato un dibattito con uno degli ingegneri della piattaforma (come sviluppatore mobile) sui codici restituiti.
Lo scenario è: quando provi a creare una risorsa, il server restituisce un 201 con resource_id in header . Mi sarei aspettato una risposta 201 con un JSON body con resource_id . A mio parere, ciò sarebbe più facile da analizzare per i client mobili.
Ho sbagliato a pensare in questo modo? Dovrei davvero analizzare headers ?
Esaminare RFC2616, nella sezione relativa al 201 codice di risposta creato , troviamo:
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.
Quindi, mettere quell'identificatore di risorsa in un campo di intestazione Location è perfettamente legittimo. Ma, leggendo ulteriormente, troviamo:
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 altre parole, il server dovrebbe fornire la nuova posizione della risorsa come parte del corpo della risposta, formattata in base al tipo di contenuto richiesto.
Per update , non è necessario che tu debba analizzare qualcosa di diverso dal codice di stato. Il contenuto aggiornato proviene dal client, quindi solo il server deve eseguire l'aggiornamento che, una volta completato, dovrebbe solo restituire 204 (Nessun contenuto).
Leggi altre domande sui tag api-design http