API REST-pourquoi utiliser PUT DELETE POST GET?

donc, je regardais à travers quelques articles sur la création D'API REST. Et certains d'entre eux suggèrent d'utiliser tous les types de requêtes HTTP: comme PUT DELETE POST GET . Nous créerions par exemple l'index .php et écrire API de cette façon:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

OK, accordé - Je ne sais pas beaucoup sur les services web (encore). Mais, ne serait-il pas plus facile d'accepter simplement JSON objet par l'intermédiaire de la POST ou GET (qui contiendrait le nom de la méthode et tous les paramètres) et répondre ensuite dans JSON aussi. Nous pouvons facilement sérialiser / deserialiser via les json_encode() et json_decode() de PHP et faire tout ce que nous voulons avec ces données sans avoir à traiter avec différentes méthodes de requêtes HTTP.

est-ce que je manque quelque chose?

mise à JOUR 1:

Ok-après avoir creusé à travers diverses API et d'apprendre beaucoup à propos de XML-RPC , JSON-RPC , SOAP , REST je suis arrivé à la conclusion que ce type D'API est sonore. En fait, stack exchange utilise à peu près cette approche sur leurs sites et je pense que ces gens savent ce qu'ils font Stack Exchange API .

143
demandé sur Community 2011-01-01 08:57:06

8 réponses

L'idée de RE présentation S tate T ransfert n'est pas à propos de l'accès aux données de la manière la plus simple possible.

vous avez suggéré d'utiliser les requêtes post pour accéder à JSON, ce qui est une façon parfaitement valide d'accéder/manipuler des données.

RESTE est une méthodologie pour significative accès aux données. Quand vous voyez une demande dans le repos, il devrait immédiatement apparente à ce qui se passe avec les données.

par exemple:

GET: /cars/make/chevrolet

va probablement retourner une liste de voitures Chevrolet. une bonne api REST pourrait même incorporer certaines options de sortie dans les requêtes comme ?output=json ou ?output=html qui permettraient à l'accessor de décider dans quel format l'information devrait être encodée.

Après un peu de réflexion sur la façon de incorporer raisonnablement la saisie de données dans une API REST, j'ai conclu que la meilleure façon de spécifier le type de données explicitement serait par l'intermédiaire de l'extension de fichier déjà existante comme: .js , .json , .html , ou .xml . Une extension de fichier manquante serait par défaut quel que soit le format par défaut (comme JSON); une extension de fichier qui n'est pas prise en charge pourrait retourner un 501 Not Implemented code d'état .

autre exemple:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

va probablement créer une nouvelle chevy malibu dans le db avec les couleurs associées. Je dis probablement car L'api REST n'a pas besoin d'être directement liée à la structure de la base de données. Il s'agit simplement d'une interface de masquage afin que les données réelles soient protégées (pensez-y comme des accesseurs et des mutants pour une structure de base de données).

maintenant nous devons passer à la question de idempotence . Généralement REST implémente CRUD sur HTTP. Utilisations HTTP GET , PUT , POST et DELETE pour les requêtes.

Un très simpliste de la mise en œuvre de REPOS pourrait use the following CRUD cartographie:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

il y a un problème avec cette implémentation: Post est défini comme une méthode non-idempotent. Cela signifie que les appels suivants de la même méthode Post entraînera différents états de serveur. Get, Put et Delete sont idempotent; ce qui signifie que les appeler plusieurs fois devrait donner un État de serveur identique.

cela signifie qu'une requête telle que:

Delete: /cars/oldest

pourrait en fait être mis en œuvre comme:

Post: /cars/oldest?action=delete

attendu que

Delete: /cars/id/123456

sera dans le même état du serveur si vous appelez ça une fois, ou si vous l'appelez 1000 temps.

une meilleure façon de traiter le retrait de l'article oldest serait de demander:

Get: /cars/oldest

et utiliser le ID des données résultantes pour faire une delete demande:

Delete: /cars/id/[oldest id]

cette méthode poserait un problème si un autre /cars était ajouté entre le moment où /oldest a été demandé et le moment où le delete a été émis.

190
répondu zzzzBov 2012-10-11 18:01:05

il s'agit d'une question de sécurité et de maintenabilité.

méthodes sûres

dans la mesure du possible, vous devez utiliser des méthodes "sûres" (unidirectionnelles) telles que GET et HEAD afin de limiter la vulnérabilité potentielle.

méthodes d'identification

dans la mesure du possible, vous devez utiliser des méthodes "idempotent" telles que GET, HEAD, PUT et DELETE, qui ne peuvent pas avoir d'effets secondaires et sont donc moins sujettes aux erreurs/plus faciles à contrôle.

Source

38
répondu markus 2011-01-01 06:06:54

en bref, le repos met l'accent sur les noms par rapport aux verbes. Lorsque votre API devient plus complexe, vous ajoutez plus de choses, plutôt que plus de commandes.

24
répondu Neil 2012-01-21 13:42:56

vous avez demandé :

ne serait-il pas plus facile d'accepter un objet JSON par le biais de $_POST normal et de répondre dans JSON aussi bien

De La Wikipedia sur REST :

RESTful applications maximisent l'utilisation de l'interface préexistante bien définie et d'autres capacités intégrées fournies par le protocole réseau choisi, et minimiser l'ajout de nouvelles fonctionnalités spécifiques sur le dessus de celui-ci

D'après ce que j'ai vu (peu), je crois que cela est généralement accompli en maximisant l'utilisation des verbes HTTP existants, et en concevant un schéma D'URL pour votre service qui est aussi puissant et évident que possible.

les protocoles de données personnalisés (même s'ils sont construits sur les protocoles standards, tels que SOAP ou JSON) sont déconseillés, et devraient être minimisés pour se conformer au mieux pour le RESTE de l'idéologie.

SOAP RPC sur HTTP, d'autre part, encourage chaque concepteur d'application à définir un nouveau vocabulaire arbitraire de noms et de verbes (par exemple getUsers (), savePurchaseOrder(...)), habituellement superposé sur le verbe HTTP 'POST'. Cela ne tient pas compte de nombreuses capacités HTTP existantes telles que l'authentification, la mise en cache et la négociation de type de contenu, et peut laisser le concepteur d'application réinventer un grand nombre de ces fonctionnalités dans le de nouveaux mots de vocabulaire.

les objets réels avec lesquels vous travaillez peuvent être dans n'importe quel format. L'idée est de réutiliser autant de HTTP QUE POSSIBLE pour exposer vos opérations que l'utilisateur veut effectuer sur ces ressources (requêtes, gestion d'état/mutation, suppression).

vous avez demandé :

est-ce que je manque quelque chose?

Il ya beaucoup plus à savoir sur le repos et la syntaxe URI / les verbes HTTP eux-mêmes. Par exemple, certains des verbes sont idempotent, d'autres ne le sont pas. Je n'ai rien vu à ce sujet dans votre question, donc je n'ai pas pris la peine d'essayer de plonger dedans. Les autres réponses et Wikipédia ont toutes deux beaucoup de bonnes informations.

en outre, il y a beaucoup à apprendre sur les différentes technologies réseau construites sur le dessus de HTTP que vous pouvez profiter si vous utilisez une API vraiment reposful. Je commencerais par l'authentification.

9
répondu Merlyn Morgan-Graham 2011-01-02 19:45:35

en ce qui concerne l'utilisation de l'extension pour définir le type de données. J'ai remarqué que L'API MailChimp le fait, mais je ne pense pas que ce soit une bonne idée.

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

Mon son comme une bonne idée, mais je pense que l'approche" plus ancien "est mieux-en utilisant des en-têtes HTTP

GET /xxx/cars/1
Accept: application/json

aussi les en-têtes HTTP sont beaucoup mieux pour la communication de type de données croisées (si jamais quelqu'un en aurait besoin)

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  
8
répondu Pawel Cioch 2014-05-15 20:09:04

est-ce que je manque quelque chose?

Oui. ;- )

ce phénomène existe en raison de la contrainte d'interface uniforme . REST aime utiliser les normes existantes au lieu de réinventer la roue. Le standard HTTP s'est déjà avéré hautement évolutif (le web fonctionne depuis un certain temps). Pourquoi devrions-nous réparer quelque chose qui n'est pas cassé?!

note: une contrainte d'interface uniforme est importante si vous voulez découpler les clients du service. Il est similaire à définir des interfaces pour les classes afin de les découpler les unes des autres. OFC. ici, l'interface uniforme se compose de normes telles que HTTP , MIME types , URI , RDF , linked data vocabs , hydraab , etc...

4
répondu inf3rno 2014-09-19 21:56:59

bonne sémantique est importante dans la programmation.

en utilisant plus de méthodes en dehors de GET / POST sera utile parce qu'il augmentera la lisibilité de votre code et le rendra plus facile à maintenir.

pourquoi?

parce que vous savez que GET va extraire des données de votre api. Vous savez que POST va ajouter de nouvelles données à votre système. Tu sais que PUT fera des mises à jour. DELETE supprimer des lignes, etc, etc,

normalement structurer mes services web RESTFUL de sorte que j'ai une fonction de rappel nommé la même chose que la méthode.

J'utilise PHP, donc j'utilise function_exists (je pense qu'il s'appelle). Si la fonction n'existe pas, je lance un 405 (Méthode non autorisée).

1
répondu HumbleWebDev 2017-07-21 20:37:09

Bill Venners: dans votre billet de blog intitulé" Why REST Failed, " vous avez dit que nous avions besoin des quatre verbes HTTP-GET, POST, PUT et DELETE - et vous avez déploré que les vendeurs de navigateur ne reçoivent et postent que."Pourquoi avons-nous besoin des quatre verbes? Pourquoi GET and POST ne sont pas assez?

Elliotte Rusty Harold: il y a quatre méthodes de base dans HTTP: GET, POST, PUT et DELETE. GET est utilisé la plupart du temps. Il est utilisé pour tout ce qui est sûr, qui ne causent pas d'effets secondaires du tout. GET est capable d'être signalisé, mis en cache, lié à, passé par un serveur proxy. C'est une opération très puissante, très utile.

POST par contre est peut-être l'opération la plus puissante. Il ne peut rien faire. Il n'y a pas de limites à ce qui peut arriver, et par conséquent, vous devez être très prudent avec elle. Vous ne le faites pas. Tu ne le caches pas. Vous n'avez pas de pré-extraction. Vous ne faites rien avec un POST sans demander le utilisateur. Voulez-vous faire cela? Si l'utilisateur appuie sur le bouton, vous pouvez afficher du contenu. Mais vous n'allez pas regarder tous les boutons d'une page, et commencer à les appuyer au hasard. En revanche navigateurs regardez tous les liens sur la page et de pré-extraction, ou de pré-extraction de ceux qu'ils pensent sont les plus susceptibles d'être suivis. Et en fait, certains navigateurs et extensions Firefox et divers autres outils ont essayé de le faire à un moment ou à un autre.

PUT and DELETE are au milieu entre GET et POST. La différence entre PUT ou DELETE et POST est que PUT et DELETE sont *idempotent, alors que POST ne l'est pas. PUT et DELETE peuvent être répétés si nécessaire. Disons que vous essayez de télécharger une nouvelle page sur un site. Dites que vous voulez créer une nouvelle page à http://www.example.com/foo.html , donc vous tapez votre contenu et vous le mettez à cette URL. Le serveur crée cette page à l'URL que vous fournissez. Maintenant, supposons que pour une raison quelconque, votre connexion réseau va vers le bas. Vous n'êtes pas sûr, n'a la demande de passer à travers, ou pas? Peut-être que le réseau est lent. Peut-être qu'il y avait un problème de serveur mandataire. Donc c'est parfaitement correct d'essayer à nouveau, ou à nouveau-autant de fois que vous le souhaitez. Parce que mettre le même document à la même URL dix fois ne sera pas différent de le mettre une fois. Il en va de même pour DELETE. Vous pouvez supprimer quelque chose dix fois, et c'est la même chose que de le supprimer une fois.

par contraste, POST, peut causer quelque chose de différent pour arriver à chaque fois. Imaginez que vous vérifiez un magasin en ligne en appuyant sur le bouton Acheter. Si vous envoyez cette demande à nouveau, vous pourriez finir par acheter tout dans votre panier une deuxième fois. Si tu l'envoies encore, tu l'achètes une troisième fois. Ce est pourquoi les navigateurs doivent être très prudent sur la répétition des opérations de poste sans consentement explicite de l'utilisateur, parce que Poste peut causer deux choses à se produire si vous le faites deux fois, trois choses si vous le faites trois fois. Avec PUT et Supprimer, il y a une grande différence entre les requêtes zéro et une, mais il n'y a pas de différence entre une requête et dix.

S'il vous plaît visitez l'url pour plus de détails. http://www.artima.com/lejava/articles/why_put_and_delete.html

mise à jour:

méthodes Idempotent Une méthode HTTP idempotent est une méthode HTTP qui peut être appelée de nombreuses fois sans résultats différents. Il n'aurait pas d'importance si la méthode est appelée qu'une seule fois, ou dix fois plus. Le résultat devrait être le même. Encore une fois, cela ne s'applique qu'au résultat, et non à la ressource elle-même. Ceci peut encore être manipulé (comme une mise à jour-timestamp, à condition que cette information ne soit pas partagée dans la représentation de la ressource (courante).

considérons les exemples suivants:

a = 4;

a++;

le premier exemple est idempotent: peu importe combien de fois nous exécutons cette instruction, a sera toujours 4. Le second exemple n'est pas idempotent. L'exécution de cette commande 10 fois aboutira à un résultat différent comme si elle était exécutée 5 fois. Puisque les deux exemples changent la valeur de a, les deux sont des méthodes non sécuritaires.

1
répondu Bimal Das 2018-01-04 09:48:40