Une API REST doit-elle être sensible à la casse ou non?
Au travail, nous avons eu un problème avec la casse REST api qui ignore les paramètres mal orthographiés sans renvoyer aucune erreur. À mon avis, c'est mauvais. Ensuite vient la question générale:
Une API REST doit-elle être sensible à la casse ou non?
Quels sont les avantages et les inconvénients de chaque approche?
Comme d'autres l'ont répondu, la partie HTTP de l'URL qui crée les API est sensible à la casse. Cela suit la convention UNIX, où les chemins URI ont été mappés aux chemins du système de fichiers et les chemins du système de fichiers sont sensibles à la casse. Windows, d'autre part, suit sa convention de rendre les chemins insensibles à la casse.
Cependant, c'est une mauvaise pratique sous Unix d'avoir deux chemins qui ne diffèrent que par la capitalisation; en outre, il est prévu que les chemins soient en minuscules.
Par conséquent: ne brisons pas les conventions.
et
ne devrait jamais cohexist. De plus, products doit être préféré à Products. Que Products doive retourner un 404, un 301 à products ou simplement être un alias de products est une question de style - c'est votre choix, mais soyez cohérent.
Les API Stack Overflow sont canoniquement minuscules et insensibles à la casse. Je pense que cela rend la vie plus facile au client, tout en ayant un défaut clair et sans surprise pour la plupart des utilisateurs.
Après tout, pouvez-vous penser à un client qui honnêtement bénéficie de la sensibilité à la casse et des noms qui se chevauchent?
Les URL HTTP ne respectent pas la casse pour le schéma et la partie hôte et sont sensibles à la casse pour le chemin, la requête et le fragment.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19
Au travail, nous avons eu un problème avec la casse REST api qui ignore les paramètres mal orthographiés sans retourner aucune erreur. À mon avis, c'est mauvais.
Alors ne fais pas ça. Validez vos paramètres. Appliquer les paramètres "manquants". N'envoyez pas de mauvaises demandes en premier lieu. Se conformer à une API, en particulier à un tel niveau d'orthographe des paramètres correctement, n'est pas une lourde charge.
Une API REST doit-elle être sensible à la casse ou non?
Comme cela a été mentionné, les URL sont sensibles à la casse, donc il n'y a vraiment pas beaucoup de place pour la négociation ici. Les URL/paramètres de montée/rétrogradation déroutent tout le monde et rendent vos URL non uniques. Encore une fois, ce n'est pas une demande extrême de s'attendre à ce que les implémenteurs utilisent les URL appropriées. Ces URL ne sont (très probablement) pas saisies par des personnes aléatoires, elles sont implémentées du code ou des pages Web. Enfin, cela n'a d'incidence que sur les URL des points d'entrée. Les autres URL doivent être des copies directes extraites des charges utiles car vous suivez HATEOAS. Ces URL ne devraient pas du tout être gâchées et simplement renvoyées.
Simplement, si la sensibilité à la casse est un problème, vous le faites mal.
Quels sont les avantages et les inconvénients de chaque approche?
Les avantages sont la cohérence, la clarté et la bonne application de votre API. Il n'y a aucun inconvénient.