Che tipo MIME se JSON viene restituito da a REST API?
La mia REST API restituisce JSON.
Attualmente sto restituendo text/plain come tipo MIME, ma mi sembra divertente . Devo restituire application/x-javascript o qualche altro tipo?
La seconda domanda riguarda il codice di stato HTTP per le condizioni di errore . Se l'API REST restituisce uno stato di errore, restituisco come JSON
{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }
Il codice di stato HTTP dovrebbe rimanere su 200 OK?
Il JSON spec suggerisce application/json, e questo sembra essere supportato dal IETF e IANA registry.
Sulla seconda domanda, penso che se la gestione dei messaggi fallisce in qualche modo dovresti restituire una risposta agli errori strutturata e standard come un messaggio JSON; solo se c'è un errore nel recapitare il messaggio al gestore di backend per qualche motivo, dovresti considerare un codice di errore HTTP.
Aggiornamento 2014-06-27: I giorni in cui i client (browser) funzionavano solo con una risposta di 200 sono passati e il consiglio prevalente per le API RESTful è quello di utilizzare i codici di risposta HTTP appropriati per la risposta, 2xx per le risposte riuscite ( ad es. 201 Created for PUT; 204 No Content per DELETE) e 4xx e 5xx per tutte le condizioni di errore, comprese quelle dell'API stessa.
Il tipo MIME di JSON è
application/json
http://www.ietf.org/rfc/rfc4627.txt
http://www.iana.org/assignments/media-types/application/
Più specificamente qui:
Preferisco rispondere sia con uno stato di errore HTTP che con un payload specifico dell'applicazione.
No, non si dovrebbe restituire 200 in una condizione di errore.
È possibile ripetere il codice di stato o includere un codice di errore più dettagliato nel payload della risposta.
Il Content-type corretto da restituire è application/json, in base a RFC 4627 , che registra anche il tipo MIME IANA (e infatti, viene visualizzato nella pagina IANA). Naturalmente, se dovessi scrivere un cliente, vorrai essere più liberale in ciò che accetti, e accettare anche altri come text/json e text/x-json.
Ora, se c'è un errore dovresti non restituire HTTP 200, che è fondamentalmente non RESTful. So che a volte non c'è una corrispondenza esatta per il tuo errore, ma scegli gli errori 4XX (errore del client) o 5XX (errore del server) più vicino in RFC 2616 Sezioni 10.4 - 10.5 ed essere più preciso nel JSON.
Se per "API REST" si intende che si desidera seguire un'architettura REST, il tipo di supporto da utilizzare è determinato dalla funzionalità che si desidera esporre tramite l'API REST. Vuoi essere in grado di creare nuovi oggetti? Interrogare una lista di oggetti? Modifica un oggetto? Se è così, allora un buon tipo di media RESTful da usare potrebbe essere vnd.collection + json perché definisce un'interfaccia collegata ipertestuale per manipolare una raccolta di oggetti json.
Nota: Un'API RESTful potrebbe utilizzare l'applicazione di tipo multimediale/json, ma questo tipo di supporto non ha un'interfaccia RESTful collegata ipertestuale, quindi sarebbe un punto finale nella modifica dello stato.
È inoltre completamente accettabile seguire un'architettura API Web, in cui le chiamate RPC HTTP restituiscono oggetti application/json e altre chiamate RPC HTTP manipolano tali oggetti e non esiste un'interfaccia di collegamento ipertestuale per l'utilizzo e la navigazione delle modifiche di stato. Ma questo non è REST.
Mi piace questa descrizione di REST (dal creatore di REST):
REST APIS deve essere guidato ipertestuale
In altre parole, se il motore dello stato dell'applicazione (e quindi l'API) non è guidato dall'ipertesto, quindi non può essere RESTful e non può essere un'API REST. Periodo.
Inoltre, dalla discussione di quel post c'è questo esempio di un'applicazione RESTful: Applicazione Lost Boys's Spam-E REST