API REST : en-têtes HTTP personnalisés et paramètres URL

Question

Quand utilisez-vous des en-têtes HTTP personnalisés dans la partie requête d'une API REST ?

Exemple :

Est-ce que vous utiliseriez

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

au lieu de

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

Answer 1

L'URL indique la ressource elle-même. Un "client" est une ressource sur laquelle on peut agir, et qui doit donc faire partie de l'URL de base : /orders/view/client/23 .

Les paramètres ne servent qu'à paramétrer l'accès à la ressource. Ceci est particulièrement vrai pour les messages et les recherches : /orders/find?q=blahblah&sort=foo . La frontière est mince entre les paramètres et les sous-ressources : /orders/view/client/23/active versus /orders/view/client/23?show=active . Je recommande le style sous-ressource et réserve les paramètres pour les recherches.

Puisque chaque point de terminaison REprésente un transfert d'état (pour manier la mnémonique), les en-têtes personnalisés ne devraient être utilisés que pour les choses qui n'impliquent pas le nom de la ressource (l'url), l'état de la ressource (le corps) ou les paramètres affectant directement la ressource (les paramètres). Cela laisse les véritables métadonnées sur la demande pour les en-têtes personnalisés.

HTTP dispose d'une très large sélection de collecteurs qui couvrent la plupart de vos besoins. J'ai déjà vu des en-têtes personnalisés dans le cadre d'une requête de système à système opérant pour le compte d'un utilisateur. Le système proxy valide l'utilisateur et ajoute " X-User: userid "dans les en-têtes et utiliser les informations d'identification du système pour accéder au point de terminaison. Le système récepteur valide que les informations d'identification du système sont autorisées à agir au nom de l'utilisateur, puis valide que l'utilisateur est autorisé à effectuer l'action.

Answer 2

Utilice En-têtes HTTP pour l'envoi,

• Directives ( lire l'entrée au format JSON )

• Métadonnées (qui fait la demande)

• Données communes à envoyer à chaque demande (comme l'authentification), la session)

Utilice Paramètres du chemin à faire,

• Demandes spécifiques sur une ressource ( /country/state/city )

  Ils doivent former une hiérarchie logique

Utilice Paramètres d'interrogation pour l'envoi,

• Demandes d'action sur une ressource (comme la pagination, les filtres)

Answer 3

Je n'utiliserais un en-tête personnalisé que lorsqu'il n'y a pas d'autre moyen de transmettre des informations par standard ou convention. Darren102 explique la manière typique de passer cette valeur. Votre API sera beaucoup plus conviviale en utilisant les modèles typiques plutôt que les en-têtes personnalisés. Cela ne veut pas dire que vous n'aurez pas à les utiliser, mais qu'ils devraient être utilisés en dernier recours et comme quelque chose qui n'est pas déjà géré par la spécification HTTP.

Answer 4

Les en-têtes personnalisés présentent les avantages suivants :

• Préserve les urls des problèmes de sécurité (plus sûres, pas dans les caches des navigateurs/proxy).

Personnellement, je ne les utiliserais qu'en interne, entre mon propre code web et mon propre serveur web, au cas où j'aurais besoin de quelque chose de spécial.

Answer 5

Quand utilisez-vous... les en-têtes HTTP dans la partie requête d'une API REST ?

Authentification : GUIDs, authentification de base, jetons personnalisés, etc. ex, Authentification de base avec un jeton Guid pour l'api REST au lieu de nom d'utilisateur/mot de passe

Si vous êtes amené à transmettre des jetons ou d'autres informations de type authentification entre des domaines couverts par la norme PCI-DSS ou d'autres règles de sécurité, vous devrez peut-être aussi enterrer les paramètres, car certaines réglementations exigent explicitement que les éléments d'authentification ne figurent pas dans les URL susceptibles d'être rejoués de manière triviale (à partir des historiques de navigation, des journaux de proxy, etc.)