Quel type MIME si JSON est renvoyé par une API REST?

Question

Mon API REST renvoie JSON.

Je retourne actuellement text / plain sous le type MIME, mais c'est drôle. Devrais-je retourner application/x-javascript ou un autre type?

La deuxième question concerne le code de statut HTTP pour les conditions d'erreur. Si mon API REST renvoie un état d'erreur, je retourne au format JSON.

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

Le code d'état HTTP doit-il rester à 200 OK ?

Answer 1

Le JSON spec suggère application/json, et qui semble être pris en charge par l' IETF et de l'IANA registre.

Sur la deuxième question, je pense que si le traitement de message d'échec d'une certaine façon, il faut retourner une forme structurée et erreur standard de la réponse JSON message, et seulement s'il existe une impossibilité de livrer le message sur le serveur gestionnaire pour quelque raison devriez-vous envisager un code d'erreur HTTP.

Mise à jour 2014-06-27: Les jours où les clients (navigateurs) seulement travaillé avec une réponse 200 sont, depuis longtemps, et la vigueur des conseils pour RESTful Api est d'utiliser des codes de réponse HTTP appropriée pour la réponse, 2xx pour le succès des interventions (par exemple, 201 Créé pour METTRE; 204 Aucun Contenu pour les SUPPRIMER) et 4xx et 5xx pour toutes les conditions d'erreur, y compris ceux de l'API en elle-même.

Answer 2

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:

http://www.ietf.org/rfc/rfc4627.txt

Answer 3

Non, vous ne devriez pas retourner 200 en cas d'erreur.

Vous pouvez répéter le code d'état ou inclure un code d'erreur plus détaillé dans la charge de la réponse.

Answer 4

Le bon Content-type de retour est - application/json, selon la RFC 4627, qui enregistre également le type MIME de l'IANA (et en effet, il s'affiche sur l'IANA page). 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 qu' text/json et text/x-json.

Maintenant, si il y a une erreur, pas de retour HTTP 200, qui est fondamentalement non-Sommeil. Je sais que, parfois, il n'y a pas de correspondance exacte pour votre erreur, mais choisir le plus proche 4XX (faute du client) ou 5XX (serveur de faute) des erreurs dans la RFC 2616 les Sections 10.4-10.5, et être plus précis dans le JSON.