Une "dimension" de ce sujet a été laissée de côté, mais elle est très importante: il y a des moments où les "meilleures pratiques" doivent être en accord avec la plateforme que nous mettons en œuvre ou augmentons avec les capacités REST.
Exemple pratique:
De nombreuses applications web implémentent aujourd'hui l'architecture MVC (Model, View, Controller). Ils supposent qu'un certain chemin standard est fourni, d'autant plus lorsque ces applications Web sont livrées avec une option "Activer les URL SEO".
Pour ne citer qu'une application web assez célèbre: une boutique e-commerce OpenCart. Lorsque l'administrateur active les «URL SEO», il s'attend à ce que ces URL soient fournies dans un format MVC assez standard comme:
http://www.domain.tld/special-offers/list-all?limit=25
Où
special-offers
est le contrôleur MVC qui doit traiter l'URL (montrant la page des offres spéciales)
list-all
est le nom de l'action ou de la fonction du contrôleur à appeler. (*)
limit = 25 est une option, indiquant que 25 éléments seront affichés par page.
(*) list-all
est un nom de fonction fictif que j'ai utilisé pour plus de clarté. En réalité, OpenCart et la plupart des frameworks MVC ont une fonction implicite (et généralement omise dans l'URL) index
par défaut qui est appelée lorsque l'utilisateur souhaite qu'une action par défaut soit effectuée. L'URL du monde réel serait donc:
http://www.domain.tld/special-offers?limit=25
Avec une application ou une structure frameworkd désormais assez standard similaire à celle ci-dessus, vous obtiendrez souvent un serveur Web qui est optimisé pour cela, qui réécrit les URL pour cela (la vraie "URL non SEOed" serait:) http://www.domain.tld/index.php?route=special-offers/list-all&limit=25
.
Par conséquent, en tant que développeur, vous devez gérer l'infrastructure existante et adapter vos "meilleures pratiques", sauf si vous êtes l'administrateur système, savez exactement comment modifier une configuration de réécriture Apache / NGinx (cette dernière peut être désagréable!), Etc. sur.
Ainsi, votre API REST serait souvent bien meilleure en suivant les normes de l'application Web référente, à la fois pour la cohérence avec elle et la facilité / vitesse (et donc l'économie de budget).
Pour revenir à l'exemple pratique ci-dessus, une API REST cohérente serait quelque chose avec des URL comme:
http://www.domain.tld/api/special-offers-list?from=15&limit=25
ou (URL non SEO)
http://www.domain.tld/index.php?route=api/special-offers-list?from=15&limit=25
avec un mélange d'arguments "chemins formés" et d'arguments "requête formés".