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

domanda creata a Sat, May 11, 2013 12:00 AM

La mia API REST restituisce JSON.

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

La seconda domanda riguarda il codice di stato HTTP per condizioni di errore. Se la mia 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 a 200 OK?

    
66
  1. Tutte le risposte a questo sembrano presumere che sia coinvolto un browser. La mia applicazione REST invia e risponde con messaggi JSON. Tutta la serializzazione e la de-serializzazione vengono eseguite internamente dal client e dal server. I browser di terze parti non hanno nulla a che fare con nessuno di essi, è tutto un computer molto specifico per una macchina non pubblica molto specifica. In questo caso "application /whatever_type" fa la differenza zero, è tutto solo testo. "application /json" rafforza il fatto che i dati sono json, ma solo come commento, e questo è già la prima cosa che chiunque possa lavorare con l'API dovrebbe sapere.
    2017-02-08 15: 32: 03Z
  2. @ mickeyf - Il fatto che i browser supportino il protocollo HTTP non significa che le applicazioni M2M non dovrebbero. Se vuoi scrivere un'applicazione che non supporta le intestazioni Accept e Content-Type ( tools.ietf.org/html/rfc7231#section-3.1.1.5 ) sei libero di farlo, tuttavia altri sviluppatori M2M potrebbero voler supportare più tipi di media (ad es. application /cbor) in uno standard modo.
    2018-06-25 21: 08: 32Z
6 risposte                              6                         

La specifica JSON suggerisce application/json e sembra essere supportata dal IETF e IANA registry.

Nella 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 corrette (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.

    
77
2014-06-27 20: 57: 10Z
  1. Grazie per il link alle specifiche JSON. Ho trovato un'altra domanda StackOverflow che punta a un altro tipo MIME "text /x-json". Non sei sicuro di quale sia la differenza. stackoverflow.com/questions/95554/...
    2009-01-01 03: 38: 57Z
  2. Per motivi pratici (ad esempio, ad esempio hai l'orribile client HTTP di Flex nel mix), a volte devi usare 200 per tutto. Tuttavia, in circostanze normali, si desidera utilizzare il codice di stato HTTP più appropriato per la situazione.
    2009-10-31 05: 08: 24Z
  3. @ ashitaka: questa altra domanda chiede in particolare come impostare JSON in text /x-json. Non ha alcuna pretesa di essere il tipo di media corretto per JSON.
    2011-05-25 18: 50: 17Z
19
2011-05-25 08: 39: 06Z

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

    
10
2009-05-31 18: 13: 35Z
  1. Sembra che David abbia lasciato SO, ma chiunque può supportare l'affermazione precedente e portare alcuni argomenti, perché questa è una buona (o cattiva) pratica? Secondo la risposta di Software Monkey sopra, vedo che restituire un errore HTTP con una risposta JSON valida è un'idea sbagliata. Il server deve restituire solo l'errore HTTP, se c'è un errore vero.
    2013-12-18 10: 00: 01Z

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

È corretto ripetere il codice di stato o includere un codice di errore più dettagliato nel payload della risposta.

    
10
2011-05-25 09: 25: 03Z

Il Content-type corretto da restituire è application/json, secondo RFC 4627 , che registra anche il MIME digita IANA (e in effetti compare sulla 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ù precisi nel JSON.

    
6
2011-08-01 19: 15: 24Z

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 supporto 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 tipo di media /json, ma questo tipo di media 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 da 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 di Spam-E per ragazzi

    
1
2018-03-06 04: 35: 35Z
fonte posta Qui