Obtenir le nombre de retours vus par une demande RESTful

entity-framework rest

Question

Alors, j'aimerais savoir combien de résultats je vais obtenir d'une requête RESTful uri GET. Je ne connais aucun moyen de le faire pour le moment. Y-a-t-il un moyen de faire ça? Étant donné que REST ne fait qu'émettre des propriétés, je ne sais pas s'il est capable de compter ses résultats, mais il peut ignorer les résultats et prendre un sous-ensemble de résultats.

Quelqu'un a des suggestions?

Oh, ma configuration est un LINQ to SQL qui remplit une liste générique interrogeable. Le service de données rend cette liste disponible. J'ai essayé d'obtenir un compte sur la liste, mais je récupère toujours le nombre maximal de lignes de la base de données, et ce n'est pas ce que je recherche.

Réponse acceptée

D'autres personnes pourraient avoir des objections à ce concept, mais cela me semble raisonnable:

HEAD /your/api HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 00:58:17 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 89
X-Result-Count: 100000000

Et alors:

GET /your/api HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 00:58:17 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 89
X-Result-Count: 100000000

<?xml version="1.0" encoding="UTF-8"?>
<results>
  100000000 results go here.
</results>

Remarque: une demande HEAD est utilisée ici pour obtenir le nombre sans avoir à extraire le jeu de données complet. Les requêtes HEAD récupèrent uniquement les en-têtes HTTP, pas le corps de la réponse.

Ce serait la façon la plus reposante d’indiquer le nombre de résultats que vous obtiendrez avant de l’envoyer par câble. L'astuce principale consiste à trouver le meilleur nom d'en-tête pour cela. X-Result-Count est correct, mais si vous pouvez trouver l'état de la technique et réutiliser le choix du nom de l'en-tête, ce sera encore mieux (tant qu'ils ne l'ont pas nommé comme quelque chose de vraiment stupide). Cela dit, je ne pense pas que vous aurez beaucoup de chance, vous devriez donc vous en tenir à X-Result-Count .

De plus, je pense que vous avez peut-être mal compris ce que "REST" implique réellement. Il n'y a aucune raison pour que vous ne puissiez pas donner une représentation par plage. Par exemple:

GET /your/api?page=1&perpage=10 HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 00:58:17 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 101
X-Result-Count: 10

<?xml version="1.0" encoding="UTF-8"?>
<results>
  First 10 results of 100000000 go here.
</results>

Cependant, pour être RESTful, vous devez pouvoir informer le client de la représentation identifiée par /your/api?range=0-9 ou /your/api?page=1&perpage=10 sans utiliser les informations hors bande. Par exemple, si votre page /your/api renvoie trop de résultats, effectuez une redirection temporaire vers /your/api?page=1&perpage=10 et incluez des liens hypertexte vers /your/api?page=2&perpage=10 . Notez qu'un lien hypertexte dans ce contexte pourrait être simple:

<?xml version="1.0" encoding="UTF-8"?>
<results>
  <result>
    This is a result.
  </result>
  <result>
    This is also a result.
  </result>
  <link rel="next" href="/your/api?page=3&perpage=2" />
  <link rel="prev" href="/your/api?page=1&perpage=2" />
</results>

Désormais, les informations permettant de naviguer dans les résultats de vos appels d'API sont dans la bande et en réalité RESTful.

Essentiellement, REST est un pur-vieux-HTTP avec une mise en cache bien faite et des URI raisonnables pour une bonne mesure. C'est aussi "l'hypertexte en tant que moteur de l'état de l'application" (les ressources doivent être liées à d'autres ressources). Ce n'est pas un protocole, c'est un style architectural. Quiconque vous dit différemment devrait s'appeler Roy Fielding.

Addenda:

Si vous souhaitez indiquer le nombre total par rapport au nombre de pages, vous pouvez définir l'en-tête de la manière suivante:

X-Result-Count: 0-9/100000000

Ou ajustez si nécessaire.


Réponse populaire

Pourquoi ne faites-vous pas que votre ressource traite les requêtes pour ce type de métadonnées? Supposer que

GET /items

retourne votre liste d'articles comme ceci:

<items count="5" modified="2009-10-22">
  <item url="/items/first" name="First Item" />
  <item url="/items/second" name="Second Item" />
  ...
</items>

Puis quelque chose comme:

GET /items?info

pourrait retourner une liste vide comme ceci:

<items count="5" modified="2009-10-22" type="info" />

ou éventuellement un document d'information générique comme celui-ci:

<info>
  <items count="5" modified="2009-10-22" url="/items" />
</info>

Vous pouvez également implémenter une ressource "info" comme ceci:

GET /info?items&users

qui pourrait retourner:

<info>
  <items count="5" modified="2009-10-22" url="/items" />
  <users count="8" modified="2009-10-05" url="/users" />
</info>


Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow