Les ressources ne sont-elles pas vraiment orientées objets?

Question

Quand on y réfléchit, le paradigme REST d’être axé sur les ressources ne se résume-t-il pas à être orienté objet (avec une fonctionnalité contrainte, exploitant HTTP autant que possible)?

Je ne dis pas nécessairement que c'est une mauvaise chose, mais plutôt que s'ils sont essentiellement les mêmes très similaires, il devient beaucoup plus facile de comprendre REST et les implications qu'une telle architecture entraîne.

Mise à jour: Voici des détails plus spécifiques:

1. Les ressources REST sont équivalentes aux classes publiques. Les classes / ressources privées ne sont tout simplement pas exposées.
2. L'état de la ressource est équivalent aux méthodes ou aux champs de la classe publique. Les méthodes / champs / états privés ne sont tout simplement pas exposés (cela ne veut pas dire qu'ils ne sont pas là).
3. S'il est certainement vrai que REST ne conserve pas l'état spécifique au client dans les demandes, il conserve l'état des ressources dans tous les clients. Les ressources ont l'état, de la même manière que les classes ont l'état.
4. Les ressources REST sont identifiées globalement de manière unique par un URI de la même manière que les objets serveur sont identifiés de manière globale par leur adresse de base de données, leur nom de table et leur clé primaire. Certes, il n’ya pas (encore) d’URI pour représenter cela, mais vous pouvez facilement en construire un.

Answer 1

REST est similaire à OO en ce qu’ils modélisent le monde comme des entités acceptant les messages (c'est-à-dire des méthodes), mais au-delà, ils sont différents.

L'orientation des objets met l'accent sur l'encapsulation de l'état et sur la opacité , en utilisant autant de méthodes différentes nécessaires pour agir sur l'état. REST concerne le transfert de (représentation de) l'état et la transparence . Le nombre de méthodes utilisées dans REST est limité et uniforme pour toutes les ressources toutes . La méthode la plus proche de celle de la programmation orientée objet est la méthode ToString () , qui est à peu près équivalente à un HTTP GET.

L'orientation de l'objet est avec état : vous faites référence à un objet et pouvez y appeler des méthodes tout en conservant son état au sein d'une session où l'objet est toujours dans la portée. REST est sans état - tout ce que vous voulez faire avec une ressource est spécifié dans un seul message et tout ce que vous devez savoir sur ce message est renvoyé dans une seule réponse.

En ce qui concerne l'orientation objet, il n'existe pas de concept d'identité universelle d'objet : les objets sont identifiés à tout moment par leur adresse mémoire, par un UUID spécifique à la structure ou par une clé de base de données. Dans REST, toutes les ressources sont identifiées par un URI et n'ont pas besoin d'être instanciées ni d'être supprimées. Elles existent toujours dans le cloud, sauf si le serveur répond par un 404 Introuvable . ou 410 Gone , dans le cas où vous savez qu'il n'y a aucune ressource avec cet URI.

REST offre des garanties de sécurité (par exemple, un message GET ne changera pas d'état) et d'idempotence (par exemple, une demande PUT envoyée plusieurs fois a le même effet que une fois). Bien que certaines directives relatives à des technologies orientées objet particulières expliquent comment certaines constructions affectent l’état, rien n’indique vraiment que l’orientation objet ne dit rien sur la sécurité et l’idempotence.

Answer 2

Je pense qu'il y a une différence entre dire qu'un concept peut être exprimé en termes d'objets et dire que le concept est le même même que l'orientation d'objet.

OO offre un moyen de décrire les concepts REST. Cela ne signifie pas que REST lui-même implémente OO.

Answer 3

Vous avez raison. Dan Connolly a écrit un article à ce sujet en 1997. La la thèse de Fielding en parle également.

Answer 4

Les objets groupés sont à la fois d'état et de fonctionnement L'orientation des ressources concerne explicitement la modélisation de l'état (données), la limitation de la fonction aux verbes prédéfinis à la sémantique universelle (dans le cas de HTTP, GET / PUT / POST / DELETE) et le reste du traitement à la charge du client.

Il n'y a pas d'équivalent pour ces concepts dans le monde orienté objet.

Answer 5

Uniquement si vos objets sont des objets DTO ( Objets de transfert de données ), car vous ne pouvez pas a vraiment un comportement autre que la persistance.

Answer 6

Oui, votre parallèle avec l'orientation de l'objet est correct.

Le problème, c’est que la plupart des services Web (REST, RESTful, SOAP, ..) peuvent transmettre des informations sous la forme d’objets, de sorte que ce n’est pas ce qui le rend différent. SOAP a tendance à conduire à moins de services avec plus de méthodes. REST a tendance à conduire à plus de services (1 par type de ressource) avec quelques appels chacun.

Answer 7

Oui, REST concerne le transfert d'objets. Mais ce n'est pas l'objet entier; juste l'état actuel de l'objet. L'hypothèse implicite est que les définitions de classe des deux côtés du REST sont potentiellement similaires. sinon, l'état de l'objet a été forcé dans un nouvel objet.

REST ne s'intéresse qu'à 4 événements de la vie d'un objet, créer (POST), récupérer (GET), mettre à jour (PUT) et supprimer. Ce sont des événements importants, mais il n'y en a que quatre.

Un objet peut participer à de nombreux autres événements avec beaucoup d'autres objets. Tout le reste de ce comportement est complètement en dehors de l'approche REST.

Il existe une relation étroite - REST déplace les objets - mais leur affirmation est identique, ce qui réduit vos objets à des collections de bits passifs sans méthode.

Answer 8

REST ne concerne pas uniquement les objets, il concerne également les propriétés :: une demande de publication à / users / john / phone_number avec un nouveau numéro de téléphone n’ajoute pas un nouvel objet, sa définition est une propriété de l’objet utilisateur 'john'

Il ne s'agit même pas de l'état complet de l'objet, mais seulement d'un changement apporté à une petite partie de l'état.

Ce n'est certainement pas un match 1: 1.