it-swarm-eu.dev

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?

66
ashitaka

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.

76
Lawrence Dol
19
inquam

Preferisco rispondere sia con uno stato di errore HTTP che con un payload specifico dell'applicazione.

10
david

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.

10
Julian Reschke

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.

6
LukeShu

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

0
Jason