REST-Qu'entend-on exactement par Interface uniforme?

Ok je pense que je comprends ce que cela signifie.

à Partir de Fieldings thèse:

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 composantes (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 doit être la même. IE. entre client et serveur et tous les intermédiaires, qui sont tous des composants.

votre question est assez large, vous semblez 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 se ressembler

est fondamentalement mauvais. Il n'est pas nécessaire que ces interfaces se ressemblent pour que la contrainte D'interface uniforme soit respectée. Ce qui doit être présent, est une manière uniforme à découvrez les Uri qui identifient les ressources. Cette façon uniforme est unique à chaque type de message, et il doit y avoir une certaine forme convenue. Par exemple, en HTML, une ressource d'un document renvoie à une autre par une simple balise:

<a href="URI of related resource" rel="defined relationship">fallback relationship</a>

les serveurs HTTP renvoient le html comme un type de ressource texte/html que les navigateurs ont une façon convenue d'analyser. La balise anchor est le contrôle hypermédia (HATEOAS) qui a l'identifiant unique pour la ressource liée.

le seul point que la manipulation n'était pas couverte. HTML a un autre exemple impressionnant de ceci, la balise de forme:

<form action="URI" method="verb">
  <input name=""></input>
</form>

encore une fois, le navigateur savent comment interpréter cette méta-information pour définir une représentation de la ressource a agi sur À L'URI. Malheureusement HTML ne vous permet D'obtenir et de poster que des verbes...

plus souvent dans un service basé sur JOSN, quand vous récupérez une ressource personne, il est facile de manipuler cette représentation et ensuite de la mettre ou de la Patcher directement à son URL canonique. Aucune connaissance préalable de la ressource n'est nécessaire pour la 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 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. C'est-à-dire: une commande de rendre la personne de 10 ans plus âgée analyserait la ressource à la recherche de la age, identifiez l'âge, puis ajoutez 10 ans à cette valeur, puis renvoyez cette ressource au serveur. Est-il plus facile d'avoir du code qui s'attend à ce que l'âge soit à un chemin JSON de $.l'âge? absolument...mais ce n'est pas particulièrement nécessaire.

"interface Uniforme" signifie en fait que les réponses du serveur doivent annoncer les actions et les ressources disponibles. En d'autres termes, les ressources d'interrogation devraient 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"
    }
  }]
}

juste en analysant cette réponse unique, un client sait:

1. ce qu'il a de l'interrogation (articles)
2. comment sont structurés articles (id, titre, auteur, commentaires)
3. comment récupérer des objets apparentés (c.-à-d. auteur, liste de 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 les passionnés du sujet, je recommande vivement la lecture Thomas Fielding thèse de!