J'ai fait des recherches sur REST. J'ai remarqué que l'API Amazon S utilise principalement les en-têtes http pour leur interface REST. Ce fut une surprise pour moi, car je supposais que l'interface fonctionnerait principalement hors demande paramètres.
Ma question est la suivante: dois-je développer mon REST en utilisant principalement des en-têtes http, ou dois-je utiliser des paramètres de demande?
La question est principalement si les paramètres définis font partie de l'identifiant de ressource (URI) ou non. si c'est le cas, alors vous utiliseriez les paramètres de demande sinon des en-têtes HTTP personnalisés. Par exemple, la transmission de l'ID du album
dans une galerie de musique doit faire partie de l'URI.
N'oubliez pas, par exemple /employee/id/45
(Ou /employee?id=45
, REST n'a pas de préjugé contre les paramètres de chaîne de requête ou pour URI séparés par une barre oblique propre) identifie une ressource. Vous pouvez maintenant utiliser la négociation de contenu en envoyant l'en-tête de la demande content-type: text/plain
ou content-type: image/jpg
pour obtenir les informations ou l'image. À cet égard, la ressource est réputée être la même et l'en-tête n'est utilisé que pour définir le format de la ressource.
En général, je ne suis pas un grand fan des en-têtes HTTP personnalisés. Cela suppose généralement que le client a une connaissance préalable de l'implémentation du serveur (non détectable par des moyens HTTP naturels, c'est-à-dire hypermédia) qui est toujours considéré comme un REST anti-pattern
Les en-têtes HTTP définissent généralement les aspects de HTTP orthogonal à ce qui doit être réalisé dans le processus de demande/réponse. Authorization
header (vraiment une mauvaise appellation, aurait dû être l'authentification) est un exemple classique.