REST - Qu'entend-on exactement par interface uniforme?
Interface uniforme
La contrainte d'interface uniforme est fondamentale pour la conception de tout service REST. [14] L'interface uniforme simplifie et dissocie l'architecture, ce qui permet à chaque partie d'évoluer indépendamment. Les quatre principes directeurs de cette interface sont:
Identification des ressources
Les ressources individuelles sont identifiées dans les demandes, par exemple à l'aide d'URI dans les systèmes Web REST. Les ressources elles-mêmes sont conceptuellement distinctes des représentations renvoyées au client. Par exemple, le serveur peut envoyer les données de sa base de données au format HTML, XML ou JSON, dont aucune n'est la représentation interne du serveur, et c'est la même ressource indépendamment.
Manipulation des ressources à travers ces représentations
Lorsqu'un client détient une représentation d'une ressource, y compris toutes les métadonnées attachées, il dispose de suffisamment d'informations pour modifier ou supprimer la ressource.
Messages auto-descriptifs
Chaque message contient suffisamment d'informations pour décrire comment traiter le message. Par exemple, l'analyseur à invoquer peut être spécifié par un type de support Internet (précédemment appelé type MIME). Les réponses indiquent également explicitement leur mise en cache.
Hypermédia comme moteur de l'état de l'application (A.K.A. HATEOAS)
Les clients ne font des transitions d'état que par des actions qui sont identifiées dynamiquement dans l'hypermédia par le serveur (par exemple, par des hyperliens dans l'hypertexte). À l'exception des simples points d'entrée fixes de l'application, un client ne suppose pas qu'une action particulière est disponible pour des ressources particulières au-delà de celles décrites dans les représentations précédemment reçues du serveur.
J'écoute une conférence sur le sujet et le conférencier a dit:
"Lorsque quelqu'un arrive à notre API, si vous pouvez obtenir un objet client et que vous savez qu'il existe des objets de commande, vous devriez pouvoir obtenir les objets de commande avec le même modèle que celui dont vous avez obtenu les objets client. Ces URI sont va se ressembler. "
Cela me semble faux. Il ne s'agit pas tant de l'apparence de l'URI ou de la cohérence que de la façon dont les URI sont utilisés. (identifier les ressources, manipuler les ressources par le biais de représentations, de messages auto-descriptifs et de haine).
Je ne pense pas que ce soit du tout l'interface uniforme. Qu'est-ce que ça veut dire exactement?
L'utilisation d'interfaces pour dissocier les classes de l'implémentation de leurs dépendances est un concept assez ancien. Je suis surpris que vous n'en ayez pas entendu parler ...
Par REST vous utilisez le même concept pour découpler le client de l'implémentation du service REST. Pour définir une telle interface (contrat entre le client) et le service), vous devez utiliser des normes. En effet, si vous voulez un réseau de taille Internet de REST services, vous devez appliquer des concepts globaux, comme des normes pour les faire se comprendre.
Identification des ressources - Vous utilisez la norme URI (IRI) pour identifier une ressource. Dans ce cas, une ressource est un document Web.
Manipulation des ressources via ces représentations - Vous utilisez la norme HTTP pour décrire la communication. Ainsi, par exemple, GET signifie que vous souhaitez récupérer des données sur la ressource identifiée URI. Vous pouvez décrire une opération avec une méthode HTTP et un URI.
Messages auto-descriptifs - Vous utilisez des types MIME standard et (standard) RDF vocabulaires pour rendre les messages auto-descriptifs. Ainsi, le client peut trouver les données en vérifiant la sémantique, et il n'a pas connaître la structure de données spécifique à l'application utilisée par le service.
Hypermédia comme moteur de l'état de l'application (A.K.A. HATEOAS) - Vous utilisez des liens hypertexte et éventuellement des modèles d'URI pour dissocier le client de la structure d'URI spécifique à l'application. Vous pouvez annoter ces hyperliens avec de la sémantique, par exemple Relations de liaison IANA, afin que le client comprenne ce qu'elles signifient.
La contrainte "Interface uniforme" , à laquelle toute architecture ReSTful doit se conformer, signifie en fait que les réponses du serveur doivent annoncer les actions et les ressources disponibles.
En d'autres termes, l'interrogation des ressources doit permettre au client de demander d'autres actions et ressources sans les connaître à l'avance.
JSON-API spec offre un bon exemple:
{
"links": {
"self": "http://example.com/articles",
"next": "http://example.com/articles?page[offset]=2",
"last": "http://example.com/articles?page[offset]=10"
},
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/articles/1/author"
},
},
"comments": {
"links": {
"self": "http://example.com/articles/1/relationships/comments",
"related": "http://example.com/articles/1/comments"
}
}
},
"links": {
"self": "http://example.com/articles/1"
}
}]
}
En analysant cette seule réponse, un client sait:
- ce qu'il interrogeait (articles)
- comment sont les articles structurés (id, titre, auteur, commentaires)
- comment récupérer des objets associés (c.-à-d. auteur, liste de commentaires)
- qu'il y a plus d'articles (10, basés sur la longueur de réponse actuelle et les liens de pagination)
J'espère que ça aide.
Pour ceux qui sont passionnés par le sujet, je recommande fortement de lire thèse de Thomas Fielding !
Votre question est assez large, vous semblez demander une reformulation des définitions que vous avez. Êtes-vous à la recherche d'exemples ou ne comprenez-vous pas des éléments spécifiquement énoncés?.
J'accepte que la ligne:
Ces URI vont se ressembler
est fondamentalement faux. Les URI n'ont pas besoin de se ressembler pour que la contrainte d'interface uniforme soit respectée. Ce qui doit être présent est un moyen uniforme de découvrir les URI qui identifient les ressources. Cette manière uniforme est unique à chaque type de message et il doit y avoir un format convenu. Par exemple, en HTML, une ressource de document est liée à une autre via une simple balise:
<a href="URI of related resource" rel="defined relationship">fallback relationship</a>
Les serveurs HTTP renvoient html en tant que type de ressource texte/html dont les navigateurs ont une méthode d'analyse convenue. La balise d'ancrage est le contrôle hypermédia (HATEOAS) qui a l'identifiant unique de la ressource associée.
Le seul point qui n'a pas été couvert était la manipulation. HTML a un autre exemple impressionnant de cela, la balise de formulaire:
<form action="URI" method="verb">
<input name=""></input>
</form>
encore une fois, le navigateur sait comment interpréter ces méta-informations pour définir une représentation de la ressource utilisée à l'URI. Malheureusement, HTML ne vous permet que d'obtenir et POST pour les verbes ...
plus généralement dans un service basé sur JOSN, lorsque vous récupérez une ressource Personne, il est facile de manipuler cette représentation, puis de LA REPLIQUER ou DE LA CORRIGER directement vers son URL canonique. Aucune connaissance préexistante de la ressource n'est nécessaire pour la modifier. Maintenant, lorsque nous écrivons du code client, nous sommes tous emballés avec l'idée que nous devons en fait connaître la forme avant de la consommer ... mais c'est vraiment juste pour rendre nos analyseurs efficaces et faciles. Nous pourrions faire des analyseurs qui analysent la signification sémantique de chaque partie d'une ressource et la modifier en interprétant l'intention de la modification. IE: une commande visant à rendre la personne de 10 ans plus âgée analyserait la ressource à la recherche de l'âge, identifierait l'âge, puis ajouterait 10 ans à cette valeur, puis renverrait cette ressource au serveur. Est-il plus facile d'avoir du code qui s'attend à ce que l'âge soit sur un chemin JSON de $ .age? absolument ... mais ce n'est pas spécifiquement nécessaire.
Ok je pense que je comprends ce que cela signifie.
De la dissertation Fieldings:
La caractéristique centrale qui distingue le style architectural REST des autres styles basés sur le réseau est l'accent mis sur une interface uniforme entre les composants (figure 5-6). En appliquant le principe de généralité de l'ingénierie logicielle au l'interface des composants, l'architecture globale du système est simplifiée et la visibilité des interactions est améliorée.
Il dit que l'interface entre les composants doit être la même. C'est à dire. entre le client et le serveur et tous les intermédiaires, qui sont tous des composants.