2012-11-06 3 views
4

Je viens de commencer la construction d'une API REST multilingue et je ne sais pas s'il y a une convention à suivre sur la façon dont je devrais intégrer correctement le multilinguisme.Comment organiser mon API REST multilingue?

Voici une liste d'alternatives que j'ai trouvées, sans savoir laquelle est la plus logique.

Option 1:
Langue-variable URI: http://myapi.com/en/users/john

Option 2:
retour uniquement des codes d'erreur pour le côté client de la traduction: GET http://myapi.com/users/john => HTTP 404 {status: false, error_code: "321"}

Option 3:
Renvoyer dans toutes les langues disponibles: GET http://myapi.com/users/john => {status: false, error_en: "User not found", error_sv: "Anvandaren finns inte"}

+0

Veuillez décrire le «multilinguisme correct» dans votre domaine. Peut-il y avoir différents utilisateurs 'john' pour différentes langues? –

+0

Non, les données sont les mêmes pour toutes les langues avec les noms de ressources. Seules les chaînes lisibles par l'utilisateur doivent changer – Industrial

Répondre

8

Pour content negotiation que pour négocier la langue naturelle d'une représentation, HTTP fournit le request header Accept-Language:

Accept-Language: da, en-gb;q=0.8, en;q=0.7 

Si possible, le serveur répond à cette demande avec un response header Content-Language:

Content-Language: da 

seulement si les ressources sont différentes ressources pour différentes langues, la langue devrait faire partie de l'URI. Sinon, la négociation de contenu devrait être utilisée.

+0

Dans ce cas, la négociation de contenu serait utilisée pour négocier le langage des chaînes lisibles par l'utilisateur dans la réponse uniquement. Les non-chaînes ou les chaînes non destinées aux personnes (telles que les clés d'objet) ne seront pas traduites. –

+1

@DonalFellows Oui. De la question je ne suis pas sûr si c'est ce que l'on entend par «une API REST multilingue». Mais en cas de doute, utilisez la norme :) –