REST: en-têtes HTTP ou parameters de requête

J’ai fait des recherches sur REST. J’ai remarqué que l’API Amazon S3 utilise principalement les en-têtes http pour leur interface REST. Cela a été une surprise pour moi, car je supposais que l’interface fonctionnerait principalement avec des parameters de demande.

Ma question est la suivante: devrais-je développer mon interface REST en utilisant principalement des en-têtes http, ou devrais-je utiliser des parameters de requête?

La question est principalement de savoir si les parameters définis font partie de l’identificateur de ressource (URI) ou non. Si tel est le cas, vous utiliseriez alors les parameters de requête, sinon les en-têtes personnalisés HTTP. Par exemple, le passage de l’identifiant de l’ album dans une galerie de musique doit faire partie de l’URI.

Rappelez-vous, par exemple, /employee/id/45 (Ou /employee?id=45 , REST ne préjuge pas des parameters de chaîne de requête ou des URI séparés par des barres obliques propres) identifie une ressource. Vous pouvez maintenant utiliser la négociation de contenu en envoyant un en-tête 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 personnalisés HTTP. Cela suppose généralement que le client ait 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 anti-pattern REST.

Les en-têtes HTTP définissent généralement des aspects de HTTP orthogonaux à ce qui doit être réalisé dans le processus de requête / réponse. Authorization tête d’ Authorization (vraiment un abus de langage, doit avoir été une authentification) est un exemple classique.