REST vs RESTful vs service web "normal" - le même ou pas?
J'ai lu quelques définitions et discussions sur les applications REST et/ou RESTful, mais je n'en comprends toujours pas le sens réel.
Je travaille généralement avec les applications qui récupèrent des données via GET ou envoient des données via POST vers un service Web (généralement un script PHP) qui récupère ensuite les données à partir de la base de données ou écrivez dans la base de données.
Maintenant, est-ce une application RESTful? Sinon, quelle serait une application RESTful? Quelle est la différence entre le concept RESTful et le concept avec lequel j'ai travaillé jusqu'à présent? Veuillez expliquer par un exemple.
En outre, quelqu'un parle du REST et quelqu'un des applications RESTful. J'ai trouvé que le terme REST fait référence au concept théorique, tandis que RESTful est utilisé lorsque nous parler de l'application spécifique. Est-ce vrai ou il existe de réelles différences entre les applications REST et RESTful?
Les attributs clés d'une application RESTful sont: Toutes les communications se font via http GET, POST, PUT, DELETE ET tous les éléments sont adressés via une URL standard du formulaire http://your.site.com/salesapp/salesperson/0000001/details c'est-à-dire uniquement une URL pure sans paramètres, etc. l'URL identifie la chose que GET, POST, PUT, DELETE identifie ce que vous voulez y faire.
La principale raison pour cela est que vous disposez automatiquement d'un service sans état qui peut être équilibré en charge, basculé, etc., etc.
La simple simplicité du schéma permet une interface très propre, découplant totalement le client de toute implémentation back-end particulière.
REST signifie Representational State Transfer. Si votre logiciel est conforme aux Contraintes REST alors il est considéré comme RESTful.
Bon, maintenant que j'ai sans vergogne arraché de Wikipédia, qu'est-ce que cela signifie vraiment? Cela signifie effectivement utiliser les commandes HTTP intégrées telles que GET, POST, PUT, DELETE et quelques autres plus rares pour communiquer entre un client et un serveur.
Ce que vous faites ressemble à une application RESTFul. Cependant, il y a une grande différence entre les services Web RESTFul bien conçus et les pieux. Par exemple, le code PHP à l'autre extrémité du GET peut exécuter un changement d'état, ce qui serait considéré comme incorrect car un GET est considéré comme une opération en lecture seule. Il existe de subtiles différences entre l'utilisation de POST (nouveau) et PUT (remplacement).
L'article de Wikipédia sur ce sujet est vraiment très bon, alors je m'arrête ici.
Avant d'aller plus loin, cette question connexe peut vous aider
La différence entre REST et RESTful est simplement de la sémantique. REST est un style architectural appliqué à une relation client-serveur. RESTful est simplement un moyen de dire à vos clients que vous utilisez REST.
De nombreuses applications Web prétendent être RESTful, mais en fait ne sont que partiellement conformes aux REST Constraints (comme Martijn Verburg l'a également mentionné dans sa réponse). Je vais simplement les énumérer ici, mais je vous invite fortement à lire l'article:
- Serveur client
- Cacheable
- Système en couches
- Code sur demande (facultatif)
Puisque vous mentionnez que vous travaillez côté client, il peut être utile de voir ce qu'une architecture REST vous donnera et attendra de vous en tant que client connecté. Bien que REST = n'est pas HTTP, c'est de loin le protocole le plus populaire qui prend en charge ce qui REST est donc je vais encadrer mon exemple autour de cela.
Votre client devra:
- utiliser des verbes HTTP (par exemple GET, POST, PUT, DELETE, OPTIONS, PATCH) pour effectuer les opérations pertinentes
- proposez des en-têtes Accept et comprenez les en-têtes Content-Type (par exemple, vous recevez du XML que vous n'avez jamais vu auparavant mais vous pouvez utiliser un XSD référencé pour créer un modèle de domaine côté client à présenter à votre utilisateur)
- suivez les liens proposés dans un type de contenu que vous comprenez (par exemple, faites en sorte que votre utilisateur ou votre application infère que
<link rel="pay" href="http://example.org/orders(1)/payment">en HTML exprime une transition d'état pour créer une ressource de paiement via un POST = avec un corps contenant du XML qui représente les détails du paiement comme le numéro de carte de crédit, le montant, etc.) - réagir correctement à la large gamme de codes d'état HTTP
S'il fait ce qui précède, il peut être considéré comme un client REST, vous pouvez l'appeler une "application RESTful" mais cela impliquerait plutôt que vous utilisez REST du côté client, ce qui est incorrect, il vaut donc mieux éviter le terme.
RESTful signifie que l'interface est un ensemble d'objets, qui peuvent être lus et mis à jour (et éventuellement supprimés). Autrement dit, il n'y a pas de requêtes multi-paramètres (seul le paramètre est l'objet que vous souhaitez lire) et il n'y a qu'un seul type d'opération qui change quoi que ce soit sur le serveur, téléchargement d'un nouvel état.
Ces limitations garantissent que toutes les demandes sont idempotentes (les envoyer plusieurs fois n'a aucun effet supplémentaire à les envoyer une fois). Ceci est important, car le réseau peut échouer à tout moment et ne pas fournir de demande ou de réponse et avec des demandes idempotentes, vous n'avez qu'à l'envoyer à nouveau et vous n'avez pas à effectuer une récupération compliquée.