Habituellement, je retournerais le nombre d'enregistrements dans le résultat sous forme de métadonnées. Je ne suis pas sûr que ce soit la pratique REST normale, mais ce ne sont pas beaucoup de données supplémentaires, et elles sont très précises. Il y a généralement une pagination pour de nombreux services, il est donc impossible de renvoyer d'énormes résultats à la fois. Personnellement, je suis ennuyé quand il y a une pagination pour de petits ensembles de résultats. S'il est vide, retourne number_of_records : 0
et réserve en liste / tableau vide books : []
.
{
meta: {
number_of_records : 2,
records_per_page : 10,
page : 0
},
books : [
{id:1},
{id:27}
]
}
EDIT (quelques années plus tard): La réponse de Martin Wickman est bien meilleure, voici une explication "courte".
Lors de la pagination, gardez toujours à l'esprit la possibilité de changer le contenu ou l'ordre. Comme si, la première demande arrive, 24 résultats, vous revenez en premier 10. Après cela, "nouveau livre" est inséré et vous avez maintenant 25 résultats, mais avec la demande initiale, il serait commandé à la 10ème place. Lorsque le premier utilisateur demande la 2e page, il ne recevra pas le "nouveau livre". Il existe des moyens de gérer de tels problèmes, comme fournir "l'identifiant de la requête" qui devrait être envoyé avec les appels d'API suivants, puis renvoyer la page suivante de "l'ancien" jeu de résultats, qui devrait être stocké d'une manière ou d'une autre et lié à un "identifiant de la requête". Une alternative consiste à ajouter un champ du type "liste de résultats modifiée depuis la première demande".
Généralement, si vous le pouvez, essayez de faire un effort supplémentaire et évitez la pagination. La pagination est un état supplémentaire qui peut être muté et le suivi de tels changements est sujet à des erreurs, d'autant plus que le serveur et le client doivent le gérer.
Si vous avez trop de données à traiter en même temps , envisagez de renvoyer "liste d'id" avec tous les résultats et détails d'une partie de cette liste, et fournissez des appels d'API multi_get / get_by_id_list pour la ressource.