REST API: en-têtes HTTP personnalisés et paramètres d'URL
Quand utilisez-vous des en-têtes HTTP personnalisés dans la partie requête d'une API REST?
Exemple:
Voulez-vous jamais utiliser
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
L'URL indique la ressource elle-même. Un "client" est une ressource sur laquelle on peut agir, elle devrait donc faire partie de l'URL de base: /orders/view/client/23.
Les paramètres ne sont que cela, pour paramétrer l'accès à la ressource. Cela entre surtout dans les posts et les recherches: /orders/find?q=blahblah&sort=foo. La ligne 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 de sous-ressource et les paramètres de réserve pour les recherches.
Étant donné que chaque extrémité représente un transfert d'état (pour modifier le mnémonique), les en-têtes personnalisés ne doivent être utilisés que pour des éléments n'impliquant pas le nom de la ressource (l'URL), l'état de la ressource (le corps) ou les paramètres directement. affectant la ressource (paramètres). Cela laisse de vraies métadonnées sur la demande d'en-têtes personnalisés.
HTTP propose une très large sélection d’en-têtes qui couvrent presque tout ce dont vous aurez besoin. J'ai vu des en-têtes personnalisés apparaître dans un système à une requête système fonctionnant pour le compte d'un utilisateur. Le système proxy va valider l'utilisateur et ajouter "X-User: userid "vers les en-têtes et utilisez les informations d'identification système pour atteindre le système d'extrémité. Le système récepteur vérifie que les informations d'identification système sont autorisées à agir pour le compte de l'utilisateur, puis que l'utilisateur est autorisé à effectuer l'action.
Quand utilisez-vous ... les en-têtes HTTP dans la partie requête d'une API REST?
Authentification: GUID, authentification de base, jetons personnalisés, etc. Exemple: authentification de base avec un jeton Guid pour REST api au lieu du nom d'utilisateur/mot de passe
Si vous vous engagez à 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 des paramètres, car certaines réglementations exigent explicitement que les éléments d'authentification restent en dehors des URL pouvant historiques du navigateur, journaux de proxy, etc.).
Les en-têtes personnalisés présentent les avantages suivants:
- Peut être lu facilement par les outils/scripts du réseau (authentification, méta-informations, ...)
- Garde les URL exemptes de problèmes de sécurité (plus sûr, pas dans les caches de navigateur/proxy)
- Maintient les urls plus propres: permet une meilleure mise en cache des ressources
J'utiliserais un en-tête personnalisé uniquement lorsqu'il n'existe aucun autre moyen de transmettre des informations par norme ou par convention. Darren102 explique la manière typique de transmettre cette valeur. Votre Api sera beaucoup plus conviviale en utilisant des modèles classiques en utilisant des en-têtes personnalisés. Cela ne veut pas dire que vous n’aurez pas de cas à les utiliser, mais qu’ils devraient être le dernier recours et quelque chose qui n’est pas déjà géré par la spécification HTTP.
Il n’existe pas de norme pour REST mais la méthode acceptée serait
GET /orders/view/23
Si vous n'utilisez pas les en-têtes personnalisés, la vue après 23 suppose que vous utilisez l'identifiant. Par conséquent, vous obtiendrez une fonction prenant l'identifiant et produisant uniquement cette information.
Je ne voudrais pas utiliser des en-têtes personnalisés car vous ne savez pas si des mandataires les transmettront. L'URL est la voie à suivre.
GET/orders/view/client/23
Vraiment ok:
GET /orders/view/client_id/23 or
GET /orders/view/?client_id=23
Correcte aussi:
GET /orders/view/23 or
Je penserais que ce serait bien aussi:
POST /orders/view
(custom HTTP header) CLIENT_ID: 23
Vous pouvez utiliser des en-têtes personnalisés pour inclure plus d'informations sur une demande partiellement traitée, car Enveloping n'est pas une bonne pratique. Les en-têtes sont sécurisé .