REST - Que signifie exactement Interface uniforme?

Wikipédia:

Interface uniforme

L'interface unique contrainte est essentielle à la conception de tout REPOS de service.[14] L'uniforme interface simplifie et découple l'architecture, qui permet à chaque partie d'évoluer de manière indépendante. Les quatre principes directeurs de cette interface sont:

Identification des ressources

Ressources individuelles sont identifiés dans les demandes, par exemple en utilisant l'Uri sur le web, RESTE systèmes. Les ressources elles-mêmes sont conceptuellement distincte de la représentation qui sont renvoyées au client. Par exemple, le serveur peut envoyer des données à partir de sa base de données au format HTML, XML ou JSON, dont aucun n'est le serveur interne de la représentation, et c'est la même ressource indépendamment.

La Manipulation de ressources par le biais de ces représentations

Lorsqu'un client est titulaire d'une représentation d'une ressource, y compris toutes les métadonnées attachées, il a suffisamment d'informations pour modifier ou supprimer la ressource.

Auto-descriptif des messages

Chaque message contient suffisamment d'informations pour décrire la façon de traiter le message. Par exemple, l'analyseur d'invoquer peut être spécifié par un type de média Internet (précédemment connu en tant que type MIME). Les réponses explicitement indiquer leur cacheability.

Hypermédia comme le moteur de l'état de l'application (A. K. A. HATEOAS)

Les Clients à faire les transitions de l'état uniquement à travers des actions qui sont identifiés de manière dynamique au sein de l'hypermédia par le serveur (par exemple, par des liens hypertextes à l'intérieur de l'hypertexte). Sauf pour de simples fixe de points d'entrée pour l'application, un client n'a pas supposer qu'une action particulière n'est disponible pour aucune ressource particulière au-delà de celles décrites dans les représentations précédemment reçu du serveur.

Je suis en train d'écouter une conférence sur le sujet et le professeur a dit:

"Quand quelqu'un vient à notre API, si vous êtes en mesure d'obtenir un objet client et vous savez il y a des objets d'ordre, vous devriez être en mesure d'obtenir l'ordre des objets avec le même motif que vous avez obtenu le client des objets à partir d'. Ces URI vont ressembler les uns les autres."

Cela me semble faux. Ce n'est pas tant sur ce que l'URI de ressembler, ou qu'il y a de cohérence que c'est la façon dont l'URI sont utilisés (identifier les ressources, de manipuler les ressources à travers les représentations, auto-descriptif des messages, et hateoas).

Je ne pense pas que c'est ce que l'Interface Uniforme signifie à tous. Que signifie exactement?

source d'informationauteur richard

24

À l'aide des interfaces de découplage de classes à partir de la mise en œuvre de leurs dépendances est un très vieux concept. Je suis surpris que vous n'avez pas entendu parler de lui...

En RESTE, vous pouvez utiliser le même concept pour découpler le client à partir de la mise en œuvre du service REST. Afin de définir une interface (contrat entre le client et le service), vous devez utiliser les normes. Ce est parce que si vous voulez un internet la taille du réseau de services REST, vous devez appliquer un concept global, comme les normes de leur faire comprendre les uns les autres.
- Identification des ressources - Vous utiliser l'URI (IRI) standard pour identifier une ressource. Dans ce cas, une ressource est un document web.
- La Manipulation de ressources par le biais de ces représentations - Vous d'utiliser le protocole HTTP pour décrire la communication. Ainsi, par exemple, OBTENIR les moyens que vous voulez récupérer des données sur les URI de ressources identifiés. Vous pouvez décrire une opération avec une méthode HTTP et un URI.
- Auto-descriptif des messages - Vous utiliser les types MIME et (standard) RDF vocabs de faire des messages de l'auto-descriptif. Ainsi, le client peut trouver les données en cochant la sémantique, et il n'est pas nécessaire de connaître l'application spécifique de la structure de données utilise le service.
- Hypermédia comme le moteur de l'état de l'application (A. K. A. HATEOAS) - Vous utilisez des liens hypertexte et, éventuellement, d'URI modèles pour découpler le client de l'application spécifique de la structure de l'URI. Vous pouvez annoter ces liens avec la sémantique par exemple, l'IANA lien de relations, de sorte que le client va comprendre ce qu'ils signifient.
2

Ok je crois que je comprends ce que cela signifie.

De Fieldings thèse:

La caractéristique principale qui distingue le style architectural REST à partir d'autres basées sur le réseau de styles est l'accent mis sur une interface unique entre les composants (Figure 5-6). En appliquant le génie logiciel principe de généralité à 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 doivent être les mêmes. C'est à dire. entre le client et le serveur et tous les intermédiaires, qui sont tous des composants.
2

Votre question est un peu large, vous semblez être de demander une reformulation des définitions que vous avez. Cherchez-vous des exemples ou ne comprenez-vous pas somethings spécifiquement indiqué.

Je suis d'accord que la ligne:

Ces URI vont ressembler les uns les autres

est fondamentalement mauvais. Uri n'ont rien à voir les uns les autres pour l'interface Uniforme de la contrainte d'être respectées. Ce qui doit être présent, est une manière uniforme pour découvrir les URIs identifier les ressources. Cet uniforme est unique pour chaque type de message, et il doit y avoir certains format. Par exemple, en HTML, un document de liens de ressources à un autre via un simple tag:
```
<a href="URI of related resource" >fallback relationship</a>
```
Serveurs HTTP retour html comme un texte/html type de ressource qui les navigateurs ont un accord sur la façon de l'analyse. La balise d'ancrage est l'hypermédia de contrôle (HATEOAS) qui est l'identifiant unique de la ressource reliée.

Le seul point qui n'était pas couvert était de la manipulation. HTML a un autre génial d'exemple, la balise form:
```
<form action="URI" method="verb">
  <input name=""></input>
</form>
```
de nouveau, le navigateur de savoir comment interpréter cette méta-données pour définir une représentation de la ressource utilisées à l'URI. Malheureusement HTML vous permet uniquement de GET et POST, pour les verbes...

plus souvent dans un JOSN, lorsque vous récupérez une Personne ressource, il est facile à manipuler que la représentation et puis de les METTRE ou de le corriger, le droit de retour à l'URL canonique. Pas de pré-existants connaissance de la ressource est nécessaire de le modifier. Maintenant, quand nous écrivons le code client nous obtenons tout enveloppé avec l'idée que nous n'avons en effet besoin de connaître la forme avant que nous consommons...mais c'est vraiment juste pour faire de nos analyseurs efficace et facile. Nous avons pu faire des analyseurs qui analyser le contenu sémantique de chaque partie d'une ressource et de le modifier par l'interprétation de l'intention de la modification. C'est à dire: une commande de faire de la personne de 10 ans de plus serait d'analyser les ressources de la recherche de l'âge, d'identifier l'âge, puis ajouter les 10 ans de cette valeur, puis envoyer cette ressource sur le serveur. Est-il plus facile d'avoir du code qui attend l'âge d'être au format JSON chemin de $.l'âge? absolument...mais c'est pas spécialement nécessaire.
2

"Interface uniforme" signifie en fait que les réponses du serveur devrait annoncer des actions disponibles et des ressources. En d'autres termes, l'interrogation des ressources devrait permettre au client de demander d'autres actions et des ressources, sans savoir à 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"
    }
  }]
}
```
Seulement par l'analyse de cette réponse unique, un client sait:
1. ce qu'il a de l'interrogation (articles)
2. comment sont structurés les articles (id, titre, auteur, commentaires)
3. comment faire pour récupérer des objets liés (c'est à dire l'auteur, la liste des commentaires)
4. qu'il y a plus d'articles (10, basé sur la réponse actuelle de la longueur et de la pagination des liens)
J'Espère que cette aide.

Pour ceux passionnés par le sujet, je vous recommande fortement la lecture de Thomas Fielding thèse de!

Vous devez vous connecter pour publier un commentaire.