Juste pour examiner, REST a certaines propriétés qu'un développeur doit suivre dans l'ordre pour le faire RESTful :

Qu'est-ce que le repos?

selon wikipedia:

le style architectural REST décrit les six contraintes suivantes appliquée à l'architecture, tout en laissant la mise en œuvre de la composants individuels libres de conception:

• Client–server: les serveurs ne sont pas concernés par l'interface utilisateur ou l'état utilisateur, de sorte que les serveurs peuvent être plus simples et plus évolutifs.
• Stateless: la communication client–serveur est en outre limitée par le fait qu'aucun contexte client n'est stocké sur le serveur entre les requêtes.
• Cacheable: les réponses doivent, implicitement ou explicitement, définir il s'agit d'éviter que les clients réutilisent des données périmées ou inappropriées en réponse à d'autres demandes.
• système à couches multiples: un client ne peut habituellement 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ées.
• Code à la demande (facultatif)): Les serveurs peuvent temporairement étendre ou personnaliser la fonctionnalité d'un client par le transfert de code exécutable.
• interface uniforme: l'interface uniforme entre les clients et les serveurs, examinée ci-dessous, simplifie et décompose l'architecture, ce qui permet à chaque partie d'évoluer indépendamment. (i.e. HTTP GET, POST, PUT, PATCH, DELETE)

ce que les verbes devraient faire

so user Daniel Vasallo a bien exposé les responsabilités de ces méthodes dans la question understanding REST: Verbs, error codes, and authentication :

lorsqu'il s'agit D'URI de Collection comme: http://example.com/resources /

GET: énumérer les membres de la collection, avec leur membre URIs pour plus de navigation. Par exemple, énumérez toutes les voitures à vendre.

: Sens défini comme "remplacer l'ensemble de la collection avec un autre collection."

POST: créer une nouvelle entrée dans la collection où L'ID est assigné automatiquement par la collection. L'ID créé est généralement inclus comme partie les données renvoyées par cette opération.

supprimer: ce qui signifie"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 identiques? Puis-je utiliser la deuxième variante dans tous les cas ou la documentation doit explicitement dire que je peux utiliser les deux requêtes GET et POST?

si vous rédigiez un simple vieil appel D'API RPC, ils pourraient techniquement interchangeables tant que le côté du serveur de traitement n'était pas différent entre les deux appels. Cependant, pour que l'appel soit "RESTful", appeler le point final via la méthode GET devrait avoir une fonctionnalité distincte (qui est d'obtenir des ressources) à partir de la méthode POST (qui est de créer de nouvelles ressources).

Note secondaire: il y a un certain débat sur la question de savoir si oui ou non POST devrait également être autorisé à être utilisé pour mettre à jour les ressources... bien que je ne sois pas en train de commenter ça, je te dis juste que certaines personnes ont un problème avec ce point.

j'utilise POST body pour tout ce qui n'est pas trivial et applications de ligne-of-business pour ces raisons:

1. sécurité-si nous utilisons GET avec les chaînes de requête et https, les chaînes de requête peuvent être sauvegardées dans les journaux du serveur et transmises sous forme de liens de référence. Les deux sont maintenant visibles par les administrateurs de serveur/réseau et le prochain domaine dans lequel l'utilisateur est allé après avoir quitté votre application. Ainsi, si nous envoyons une requête contenant des données PII confidentielles telles que le nom d'un client, cela peut ne pas être souhaitable.
2. longueur maximale D'URL-pas un gros problème, mais certains navigateurs ont une limite de longueur. Donc, si nous avons plusieurs éléments dans notre url comme requête, paging, champs à retourner, etc....
3. Post n'est pas un cache par défaut. Certains disent que la mise en cache est souhaitée; cependant, combien de fois ce même ensemble exact de critères de recherche pour cet objet exact pour ce client exact va-t-il se produire avant la mise en cache times out de toute façon?

BTW, j'ai également mis le champs pour rentrer dans mon corps POST que je ne souhaite pas exposer mes noms de domaine. La sécurité est comme un oignon; plusieurs couches et nous fait pleurer!

pensez-y. Lorsque votre client fait une requête GET à un URI X, ce qu'il dit au serveur est: "je veux une représentation de la ressource située à X, et cette opération ne devrait rien changer sur le serveur."Une requête PUT dit:" je veux que vous remplaciez quelle que soit la ressource située à X avec la nouvelle entité que je vous donne sur le corps de cette requête". Une demande de suppression dit :" je veux que vous supprimiez ce qui est la ressource située à X". Un PATCH est en train de dire "je suis vous donner cette diff, et vous devriez essayer de l'appliquer à la ressource à X et me dire si elle réussit."Mais un POST dit:" je vous envoie ces données subordonnées à la ressource de 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 lui, il ne fait pas de sens d'envoyer un POST à elle s'attendant à agir comme un GET.

repose sur le comportement standardisé du protocole sous-jacent, et POST est précisément la méthode utilisée pour une action qui n'est pas standardisée. Le résultat D'une requête 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, donc s'il n'est pas documenté que vous pouvez utiliser POST pour faire quelque chose, vous devez supposer que vous ne pouvez pas.

dans REST, chaque verbe HTTP a sa place et sa signification.

par exemple,

• est d'obtenir la "ressource(s)" est indiqué dans l'URL.

• POSTE est à instructure le backend de "créer" une ressource de l' 'type' a souligné dans l'URL. Vous pouvez compléter l'opération de POST avec 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" l'information en utilisant la requête, il devrait donc être une opération GET au lieu d'une opération POST.

Ce wiki peut aider à pour clarifier les choses.

Espérons que cette aide!

c'est bien que REST donne un sens aux verbes HTTP (tels qu'ils sont définis) mais je préfère être d'accord avec Scott Peal.

voici aussi l'article de L'explication détaillée de WIKI sur POST request :

il y a des moments où HTTP GET est moins adapté, même pour la récupération de données. Un exemple de ceci est quand une grande quantité de données devrait être spécifiée dans L'URL. Les navigateurs et les serveurs web peuvent avoir des limites sur le longueur de L'URL qu'ils vont gérer sans troncature ou erreur. Le pourcentage d'encodage des caractères réservés dans les URLs et les chaînes de requête peut augmenter considérablement leur longueur, et tandis que le serveur HTTP Apache peut traiter jusqu'à 4 000 caractères dans une URL,[5] Microsoft Internet Explorer est limité à 2 048 caractères dans n'importe quelle URL.[6] de même, HTTP GET ne devrait pas être utilisé lorsque des informations sensibles, tels que les noms d'utilisateurs et les mots de passe, doivent être soumis avec d'autres données pour la demande à remplir. Même si HTTPS est utilisé, empêchant les données d'être interceptées en transit, l'historique du navigateur et les journaux du serveur web contiendront probablement L'URL complète en clair, qui peut être exposé si l'un ou l'autre système est piraté. Dans ces cas, HTTP POST doit être utilisé.[7]

Je ne peux que suggérer à REST team d'envisager une utilisation plus sûre du protocole HTTP pour éviter que les consommateurs ne se heurtent à une"bonne pratique" non sécurisée.