REST API utilisant POST au lieu de GET
Supposons qu'un service offre certaines fonctionnalités que je peux utiliser comme ceci:
GET /service/function?param1=value1¶m2=value2
Est-il juste de dire que je peux l'utiliser avec une requête POST?
POST /service/function { param1 : value1, param2 : value2 }
Ces deux requêtes sont-elles les mêmes? Puis-je utiliser la deuxième variante dans tous les cas ou la documentation doit indiquer explicitement que je peux utiliser à la fois les requêtes GET et POST?
Vous ne pouvez pas utiliser API en utilisant POST ou GET s'ils ne sont pas générés pour appeler en utilisant ces méthodes séparément. Comme si votre API disait
/service/function?param1=value1¶m2=value2
est accessible en utilisant la méthode GET. Ensuite, vous ne pouvez pas l'appeler à l'aide de la méthode POST si elle n'est pas spécifiée comme méthode POST par son créateur. Si vous faites cela, vous pouvez avoir 405 Method not allowed _ statut.
Généralement, dans la méthode POST, vous devez envoyer le contenu dans le corps avec le format spécifié décrit dans content-type en-tête par ex. application/json pour les données JSON.
Et après cela, le corps de la demande est désérialisé du côté serveur. Vous devez donc transmettre les données sérialisées du client, à la décision du développeur du service.
Mais en termes généraux, GET est utilisé lorsque le serveur renvoie certaines données au client et n’a aucun impact sur le serveur, tandis que POST est utilisé pour créer des ressources sur le serveur. Donc, en général, cela ne devrait pas être pareil.
Pour rappel, REST possède certaines propriétés qu'un développeur doit suivre pour le rendre RESTful:
Qu'est-ce que le repos?
Selon Wikipédia:
Le style architectural REST) décrit les six contraintes suivantes appliquées à l’architecture, tout en laissant la possibilité de concevoir des composants individuels:
- Client – serveur: Les serveurs ne sont pas concernés par l'interface utilisateur ou l'état de l'utilisateur, ce qui permet de les simplifier et de les rendre plus évolutifs.
- Sans état: La communication client – serveur est en outre limitée par le fait qu'aucun contexte client n'est stocké sur le serveur entre les demandes.
- Cacheable: Les réponses doivent, implicitement ou explicitement, se définir comme pouvant être mises en cache, ou non, pour empêcher les clients de réutiliser des données obsolètes ou inappropriées en réponse à des demandes ultérieures.
- Système en couches: Un client ne peut généralement pas dire s'il est connecté directement au serveur final ou à un intermédiaire en cours de route. Les serveurs intermédiaires peuvent améliorer l'évolutivité du système en permettant l'équilibrage de la charge et en fournissant des caches partagés.
- Code à la demande (facultatif): Les serveurs peuvent étendre ou personnaliser temporairement les fonctionnalités d'un client en transférant du code exécutable.
- Interface uniforme: L'interface uniforme entre clients et serveurs, décrite ci-dessous, simplifie et découple l'architecture, ce qui permet à chaque composant d'évoluer indépendamment. (i.e. HTTP GET, POST, PUT, PATCH, DELETE)
Que doivent faire les verbes?
SO utilisateur Daniel Vasallo a bien présenté les responsabilités de ces méthodes dans la question Comprendre REST: verbes, codes d'erreur et authentification:
Lorsqu’il s’agit d’un URI de collection tel que: http://example.com/resources/
GET: Répertorie les membres de la collection, ainsi que leurs URI membres pour une navigation plus poussée. Par exemple, listez toutes les voitures à vendre.
PUT: Signification définie comme "remplacer la collection entière par une autre collection".
POST: Créez une nouvelle entrée dans la collection où l'ID est attribué automatiquement par la collection. L'ID créé est généralement inclus dans les données renvoyées par cette opération.
DELETE: Signification définie comme "supprimer toute la collection".
Donc, pour répondre à votre question:
Est-il juste de dire que je peux l'utiliser avec une requête POST??.
Ces deux requêtes sont-elles les mêmes? Puis-je utiliser la seconde variante dans tous les cas ou la documentation doit indiquer explicitement que je peux utiliser à la fois les requêtes GET et POST?
Si vous écriviez un ancien appel ordinaire d'API RPC, ils pourraient être techniquement interchangeables dans la mesure où le côté serveur de traitement n'est pas différent entre les deux appels. Cependant, pour que l'appel soit RESTful, l'appel du point de terminaison via la méthode GET doit avoir une fonctionnalité distincte (qui consiste à obtenir des ressources) de la méthode POST (qui est créer de nouvelles ressources).
Note latérale: il existe un débat sur la question de savoir si POST devrait également être autorisé à être utilisé pour mettre à jour des ressources ... bien que je ne fasse pas de commentaire à ce sujet, je dis simplement certaines personnes ont un problème avec ce point.
J'utilise POST body pour toutes les applications non triviales et sectorielles pour les raisons suivantes:
- Sécurité - Si nous utilisons GET avec des chaînes de requête et https, celles-ci peuvent être enregistrées dans les journaux du serveur et transférées sous forme de liens de renvoi. Les deux sont maintenant visibles par les administrateurs de serveur/réseau et par le domaine suivant auquel l'utilisateur est allé après avoir quitté votre application. Donc, si nous envoyons une requête contenant des données confidentielles PII telles que le nom du client, cela peut ne pas être souhaité.
- Longueur maximale de l'URL - Ce n'est pas un gros problème, mais certains navigateurs ont une limite de longueur. Donc, si nous avons plusieurs éléments dans notre URL comme une requête, une pagination, des champs à renvoyer, etc.
- Post n'est pas le cache par défaut. Certains disent que la mise en cache est souhaitée; Cependant, combien de fois cet ensemble exact de critères de recherche pour cet objet exact pour ce client précis va-t-il se produire avant que le cache n'expire de toute façon?
BTW, j'ai aussi mis les champs à retourner dans mon corps POST car je ne souhaite peut-être pas exposer mes noms de champs. La sécurité est comme un oignon; plusieurs couches nous font pleurer!
Pensez-y. Lorsque votre client envoie une requête GET à un URI X, il dit au serveur: "Je veux une représentation de la ressource située en X et cette opération ne doit rien changer sur le serveur." Une requête PUT dit: "Je souhaite que vous remplaciez la ressource située en X par la nouvelle entité que je vous attribue dans le corps de cette requête". Une requête DELETE indique: "Je souhaite que vous supprimiez la ressource située en X". Un PATCH dit "Je vous donne ce diff, et vous devriez essayer de l'appliquer à la ressource sur X et me dire si ça réussit." Mais un POST dit: "Je vous envoie ces données subordonnées à la ressource située sur X, et nous avons un accord préalable sur ce que vous devriez en faire."
Si vous ne l'avez pas documenté quelque part que la ressource attend un POST et fait quelque chose avec cela, cela n'a aucun sens d'envoyer un POST à il s'attend à ce qu'il agisse comme un GET.
REST repose sur le comportement normalisé du protocole sous-jacent, et POST est précisément la méthode utilisée pour une action non normalisée. Le résultat des requêtes GET, PUT et DELETE est clairement défini dans le standard, mais POST ne l'est pas. Le résultat d'un POST est subordonné au serveur. Par conséquent, si ce n'est pas documenté, vous pouvez utiliser POST pour faire quelque chose, vous devez supposer que vous ne pouvez pas.
C'est gentil que REST donne un sens aux verbes HTTP (tels qu'ils ont été définis) mais je préfère être d'accord avec Scott Peal.
Voici également un élément de l'explication étendue de WIKI sur demande POST :
HTTP GET est parfois moins approprié, même pour la récupération de données. Un exemple de cela est le cas où il faudrait spécifier une grande quantité de données dans l'URL. Les navigateurs et les serveurs Web peuvent avoir des limites quant à la longueur de l'URL qu'ils vont gérer sans troncature ni erreur. Le pourcentage d'encodage des caractères réservés dans les URL et les chaînes de requête peut considérablement augmenter leur longueur. Bien qu'Apache HTTP Server puisse gérer jusqu'à 4 000 caractères dans une URL, [5] Microsoft Internet Explorer est limité à 2 048 caractères dans toute URL. [6] De même, HTTP GET ne doit pas être utilisé là où des informations sensibles, telles que des noms d'utilisateur et des mots de passe, doivent être soumises avec d'autres données pour que la demande soit complétée. Même si HTTPS est utilisé, empêchant l'interception des données en transit, l'historique du navigateur et les journaux du serveur Web contiendront probablement l'URL complète en texte clair, qui peut être exposée si l'un des systèmes est piraté. Dans ces cas, HTTP POST devrait être utilisé. [7]
Je ne pouvais que suggérer à REST) d’envisager une utilisation plus sécurisée du protocole HTTP afin d’empêcher les consommateurs de se débattre avec des "bonnes pratiques" non sécurisées.
Dans REST, chaque verbe HTTP a sa place et sa signification.
Par exemple,
GET consiste à obtenir la "ressource (s)" indiquée dans l'URL.
Le POST consiste à charger le serveur de "créer" une ressource du "type" indiqué dans l'URL. Vous pouvez compléter l'opération POST par des paramètres ou des données supplémentaires dans le corps de l'appel POST.
Dans votre cas, puisque vous êtes intéressé à "obtenir" les informations en utilisant une requête, il devrait donc s'agir d'une opération GET au lieu d'une opération POST.
Ceci wiki peut aider pour clarifier davantage les choses.
J'espère que cette aide!