Comment charger paresseux & # 8221; d'une manière RESTful?

Question

Étant donné ce service pour obtenir des informations sur un hôtel:

> GET /hotel/{id}

< HTTP/1.1 200 OK
< <hotel>
<   <a>aaa</a>
<   <b>aaa</b>
>   <biggie>aaa....I am 300K</biggie >
< </hotel>

Le problème est que biggie est égal à 300 Ko et que nous ne souhaitons pas le renvoyer à chaque réponse. Quelle est la méthode RESTful pour charger paresseux cette valeur?

Faut-il configurer deux ressources:

> GET /hotel/{id}

< HTTP/1.1 200 OK
< <hotel>
<   <a>aaa</a>
<   <b>aaa</b>
< </hotel>

et ..

> GET /hotel/{id}/biggie

< HTTP/1.1 200 OK
< <biggie>
<   <val>aaa....I am 300K</val>
< </biggie>

Et vous ne demandez à GET / hotel / {id} / biggie que lorsque vous avez vraiment besoin de ces données?

Cela fonctionnerait .. bien qu'il n'y ait rien de spécial à propos de biggie si ce n'est qu'il s'agit d'un ensemble de données volumineux. Je pense qu'il est préférable de tout garder au niveau hôtel car tous les attributs ne sont en réalité que des attributs du hôtel .

Answer 1

N'oubliez pas que l'hypermédia est votre ami.

GET /hotel/{id}

HTTP/1.1 200 OK
<hotel Id="99">
  <a>aaa</a>
  <b>aaa</b>
  <biggieLink href="/Hotel/99/Biggie"/>
</hotel>

ou vous pouvez même faire

GET /hotel/{id}

HTTP/1.1 200 OK
<hotel Id="99">
  <a>aaa</a>
  <b>aaa</b>
  <biggieSynopsis href="/Hotel/99/Biggie">
    <title>Here is a a summary of biggie</title>
  </biggieSynopsis
</hotel>

Answer 2

Le configurer comme deux ressources fonctionnerait, mais si vous n'aimez pas cela, vous pourriez envisager d'utiliser la mise en cache; En fonction de la nature des données, cela vous évitera peut-être plus de travail que de les scinder en plusieurs ressources.

Answer 3

Je pense que votre solution est correcte. Il n'y a pas de réponse parfaite, mais trois possibilités sont:

1. Envoyez tous les attributs à chaque fois
2. Envoyez les attributs individuellement comme demandé ( / {id} / a , / {id} / b , / {id} / biggie )
3. Envoyez tous les attributs SAUF pour les inhabituels, comme vous le suggérez.

1 et 2 sont intéressants parce qu'ils sont uniformes, mais 3 est logique dans votre cas, ou dans le cas où un élément de données nécessite des informations de connexion, par exemple.

(2 présente également l'inconvénient de nécessiter un couplage plus étroit avec le demandeur, qui doit connaître le nom de chaque attribut.)