Quale tipo MIME se JSON viene restituito da un'API REST?

StackOverflow https://stackoverflow.com/questions/404470

Domanda

La mia API REST restituisce JSON.

Attualmente sto restituendo text / plain come tipo MIME, ma mi sembra divertente. Dovrei restituire application / x-javascript o qualche altro tipo?

La seconda domanda riguarda il codice di stato HTTP per le condizioni di errore. Se la mia API REST sta restituendo uno stato di errore, sto tornando come JSON 

{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }

Il codice di stato HTTP deve rimanere su 200 OK ?

È stato utile?

Soluzione

Le specifiche JSON suggeriscono application / json e che sembra essere supportato da IETF e IANA registro.

Sulla seconda domanda, penso che se la gestione dei messaggi fallisce in qualche modo dovresti restituire una risposta di errore strutturata e standard come messaggio JSON; solo se si verifica un errore nel recapitare il messaggio al gestore back-end per qualche motivo, si dovrebbe prendere in considerazione un codice di errore HTTP.

Aggiornamento 27/06/2014 : i giorni in cui i client (browser) hanno lavorato solo con una risposta 200 sono passati da molto tempo e il consiglio prevalente per le API RESTful è quello di utilizzare i codici di risposta HTTP appropriati per la risposta , 2xx per risposte riuscite (ad es. 201 creato per PUT; 204 nessun contenuto per DELETE) e 4xx e 5xx per tutte le condizioni di errore, comprese quelle dell'API stessa.

Altri suggerimenti

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

No, non dovresti restituire 200 in una condizione di errore.

Va ??bene ripetere il codice di stato o includere un codice di errore più dettagliato nel payload della risposta.

Il tipo di contenuto corretto da restituire è application / json , secondo RFC 4627 , che registra anche il tipo MIME IANA (e in effetti, appare nella pagina IANA). Ovviamente, se dovessi scrivere un client, vorresti essere più liberale in ciò che accetti e anche accettarne altri come text / json e text / x-json .

Ora, se si verifica un errore, non restituire HTTP 200, questo è fondamentalmente non RESTful. So che a volte non esiste una corrispondenza esatta per il tuo errore, ma scegli gli errori 4XX (errore del client) o 5XX (errore del server) più vicini in RFC 2616 Sezioni 10.4 -10.5 ed essere più preciso in JSON.

Se tramite " API REST " vuoi dire che vuoi seguire un'architettura REST quindi il tipo di supporto da usare è determinato dalla funzionalità che vuoi esporre attraverso l'API REST. Vuoi essere in grado di creare nuovi oggetti? Richiedere un elenco di oggetti? Modifica un oggetto? In tal caso, un buon tipo di supporto RESTful da utilizzare potrebbe essere vnd.collection + json perché definisce un'interfaccia ipertestuale collegata per manipolare una raccolta di oggetti json.

Nota: un'API RESTful potrebbe utilizzare il tipo di supporto application / json, ma questo tipo di supporto non ha un'interfaccia RESTful collegata all'ipertesto, quindi sarebbe un punto finale nella modifica dello stato.

È anche del tutto accettabile seguire un'architettura API Web, in cui le chiamate HTTP RPC restituiscono oggetti application / json e altre chiamate HTTP RPC 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):

L'API REST deve essere guidato dall'ipertesto

  

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: Lost Applicazione REST Spam-E per ragazzi

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top