Quel type MIME si JSON est retourné par une API REST?
mon API REST renvoie JSON.
je retourne actuellement text/plain comme type MIME, mais ça fait drôle.
Dois-je retourner application/x-javascript ou un autre type?
la deuxième question concerne le code D'état HTTP pour les conditions d'erreur. Si mon API REST renvoie un État d'erreur, je renvoie JSON
{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }
le code D'état HTTP doit-il rester 200 OK ?
6 réponses
Le JSON spec suggère application/json , et qui semble être pris en charge par le IETF et IANA du registre.
à la deuxième question, je pense que si le traitement du message échoue d'une manière ou d'une autre, vous devriez retourner une réponse d'erreur structurée et standard comme un message JSON; seulement s'il y a un défaut de livrer le message au gestionnaire d'arrière-plan pour une raison quelconque, vous devriez considérer un Code D'erreur HTTP.
mise à jour 2014-06-27 : les jours où les clients (navigateurs) n'ont travaillé qu'avec une réponse de 200 sont loin derrière et le Conseil dominant pour les API Reposful est d'utiliser des codes de réponse HTTP appropriés pour la réponse, 2xx pour les réponses réussies (par exemple 201 créé pour PUT; 204 pas de contenu pour DELETE) et 4xx et 5xx pour toutes les conditions d'erreur, y compris ceux de L'API elle-même.
le type MIME de JSON est
application/json
http://www.ietf.org/rfc/rfc4627.txt
http://www.iana.org/assignments/media-types/application /
plus spécifiquement ici:
Non, vous ne devriez pas retourner 200 dans une condition d'erreur.
il est correct de répéter le code d'état, ou d'inclure un code d'erreur plus détaillé dans la charge utile de réponse.
le bon Content-type à retourner est application/json , selon RFC 4627 , qui enregistre également le MIME de type IANA (et en effet, il apparaît sur la page de IANA). Bien sûr, si vous deviez écrire un client, vous souhaitez être plus libéral dans ce que vous acceptez, et aussi accepter les autres tels que text/json et text/x-json .
maintenant, s'il y a une erreur, vous devez et non retourner HTTP 200, c'est fondamentalement non-Sommeil. Je sais que parfois il n'y a pas de correspondance exacte pour votre erreur, mais choisissez les erreurs 4XX (défaut du client) ou 5XX (défaut du serveur) les plus proches dans RFC 2616 Sections 10.4 -10.5, et soyez plus précis dans le JSON.
si par" API REST " vous voulez dire que vous voulez suivre une architecture REST, alors le type de média à utiliser est déterminé par la fonctionnalité que vous voulez exposer à travers L'API REST. Voulez-vous pouvoir créer de nouveaux objets? Requête une liste d'objets? Modifier un objet? Si oui, alors un bon type de média reposant à utiliser pourrait être vnd.collection+json parce qu'il définit une interface hypertexte liée pour manipuler une collection d'objets json.
Note: une API RESTful pourrait utiliser le type de média application / json, mais ce type de média n'a pas d'interface RESTful hypertexte liée, il serait donc un point final dans le changement d'état.
il est également tout à fait acceptable de suivre une architecture D'API web, où les appels HTTP RPC renvoient des objets application/json, et d'autres appels HTTP RPC manipulent ces objets, et il n'y a pas d'interface de lien hypertexte pour utiliser et naviguer dans les changements d'état. Mais ce n'est pas en RESTE.
j'aime ça Description du repos (du créateur du repos):
RESTE API doit être hypertexte dirigé
en d'autres termes, si le moteur d'application (et donc L'API) n'est pas motivé par l'hypertexte, alors il ne peut pas être reposant et ne peut pas sois une API de repos. Période.
aussi, de la discussion de ce poste est cet exemple d'une application Reposful: Garçons Perdus Spam-e REST Application