La langue anglaise est-elle un standard pour décrire un Webservice (Rest, SOAP etc.)?

Je ne pense pas qu'il y ait de norme, mais je dirais simplement: il pourrait y avoir de nombreuses façons dont votre code peut être utilisé par des personnes avec un autre langage. Donc, s'en tenir à l'anglais est le meilleur moyen de le rendre compréhensible et utilisable par n'importe qui.

Étant moi-même de langue maternelle espagnole, je ne vois aucune justification technique pour écrire une API dans autre chose que l'anglais, le langage technique de facto.

Si l'intention est de développer une API qui est insoluble pour quiconque en dehors du monde hispanophone, je suppose que ce serait la voie à suivre.

Pourtant, je vois que cela se produit encore et encore parmi les projets logiciels hispanophones. Je pense que c'est préjudiciable.

OTH, penchons-nous sur Rakuten, l'une des entreprises technologiques les plus puissantes du Japon. Rakuten a décidé de faire de l'anglais la langue de travail de tous ses employés, même si l'essentiel de ses activités se situe au Japon.

Cela vous dit quelque chose. Dans le monde du 21e siècle connecté à l'échelle mondiale, orientez vos produits vers le plus large public.

Je ne peux pas invoquer une raison axiomatique pour le faire (comme je dirais "ne pas utiliser les instructions goto.") Mais écrire quelque chose en autre que l'anglais est quelque chose que je ne ferais pas.

Je suis un hispanophone bilingue espagnol-anglais vivant et travaillant en Espagne. Dans plusieurs de mes projets de développement de logiciels informatiques, je travaille dans des équipes internationales collaborant avec des personnes en Inde, en France et au Royaume-Uni. Dans ces scénarios, il est judicieux d'être compris dans un langage commun à tous. D'un autre côté, j'ai également travaillé sur des projets où le client ne parlait qu'une langue régionale et il n'était pas nécessaire d'utiliser ni l'espagnol ni l'anglais. Cela dépend vraiment qui sont vos collègues et qui sont vos utilisateurs finaux.

Utiliser une autre langue comme l'anglais vous oblige toujours à remplacer les caractères spéciaux de votre langue, comme les accents et ñ et des trucs comme ça. Mais cela peut être résolu.

La question est: qui va utiliser votre service? Si les consommateurs ne sont pas hispanophones, ils apprécient certainement l'anglais.

Cependant, d'après mon expérience, vous avez souvent des noms très spécifiques à un domaine, qui parfois ne peuvent pas être traduits correctement en anglais ou il est difficile de savoir quel serait le bon mot en anglais car les traducteurs vous donnent souvent des traductions étranges pour votre des mots spécifiques au domaine (espagnol). J'ai donc vu de nombreux Webservices traduits en anglais mais je devais encore me demander: qu'est-ce que cela signifie? parce que la traduction n'avait tout simplement pas de sens.

Par conséquent, mon avis est d'utiliser l'espagnol, à moins que votre Webservice ne soit réellement utilisé en dehors du monde hispanophone. Parce que s'il est consommé en dehors du mot espagnol, une bonne traduction est également disponible.

Je suis de langue maternelle allemande et ma langue de travail est principalement l'anglais (travaillant pour une entreprise américaine), certainement en ce qui concerne le codage. En gros, tous mes logiciels professionnels sont également réglés en anglais, et je dois même dire que je suis confus quand je le vois en allemand ;-) Mon point est donc que, de mon point de vue quotidien, je n'envisagerais même pas d'utiliser ma langue maternelle pour le codage.

Cependant, à un niveau plus général, je voudrais faire valoir qu'une API devrait être créée de telle manière que le consommateur puisse facilement dire à partir du nom du point de terminaison ce qu'il est censé faire. Donc, comme certains l'ont mentionné ci-dessus, je pense qu'il vaut la peine de se demander qui est finalement le consommateur. Si vous avez un public cible fermé, parlant tous la même langue, ne prévoyez pas d'exposer l'API à l'extérieur, alors je pourrais bien imaginer créer les étiquettes des points de terminaison dans cette langue.

Deux autres points à considérer: - Pouvez-vous être sûr que tous les (futurs) développeurs parlent ce langage et que cela ne devrait pas être déroutant pour eux? - Qu'en est-il de fournir aux points de terminaison de l'API des étiquettes dans les deux langues? Selon le langage de programmation / cadre que vous utilisez, je pense qu'il pourrait être assez simple de dupliquer les points de terminaison, mais en appelant la même logique. Je ne suis pas sûr que ce soit une bonne pratique, mais s'il y a un avantage pour les consommateurs, et que vous souhaitez quand même vous en tenir à la langue de travail pour être sûr, je pourrais l'imaginer.

Je pense que si votre équipe (et les futurs développeurs de votre projet / entreprise) et votre client sont hispanophones, vous pouvez utiliser l'anglais ou l'espagnol comme vous le souhaitez. Mais si vous pensez qu’à tout moment un locuteur non espagnol codera ou utilisera votre API, vous devriez utiliser l’anglais.