Nous avons une recherche / liste-ressource:
interne, la taille de la page est statique et renvoie 20 éléments. L'utilisateur peut avancer en augmentant le numéro de page. Mais pour être plus flexible, nous pensons maintenant également à exposer la taille d'une page:
En tant que tel, ceci est flexible car le client peut désormais décider des appels réseau vs. Taille de la réponse, lors de la recherche. Bien sûr, cela a l'inconvénient que le serveur pourrait être touché par accident ou par maliciité exprès:
Pour la robustesse, la solution pourrait être de configurer une limite supérieure de la taille de la page (par exemple 100) et lorsqu'elle est dépassée, représente une réponse d'erreur ou une redirection HTTP à l'URL avec le paramètre de taille de page le plus élevé possible.
Que pensez-vous?
http: // xxxx / utilisateurs /? Page = 1
http: // xxxx / users /? Page = 1 & Taille = 20
http: // xxxx / utilisateurs /? Page = 1 & Taille = 1000000
3 Réponses :
Gérer l'accès aux ressources est toujours une bonne idée de la protection des interfaces extérieures : En d'autres termes, mettez une limite sensible.
La redirection pourrait être une bonne idée lorsqu'il s'agit du temps de développement, c'est-à-dire lorsque l'utilisateur de l'API est familiarisé avec le service, mais en dehors de cette situation, je doute qu'il y a de la valeur.
Assurez-vous que les paramètres sont bien documentés de chaque sens.
Personnellement, je voudrais simplement documenter une taille maximale de page et quelque chose de plus grand que celui qui est simplement traité comme maximum.
Avez-vous testé cela pour voir s'il s'agit d'une préoccupation? Si un utilisateur demande une taille de page d'un million, cela provoque-t-il vraiment toutes vos autres demandes d'arrêter / lent? Si oui, je pourrais d'abord regarder votre architecture sous-jacente. Mais si, à la fin, il s'agit d'un problème que je ne pense pas à définir une limite difficile à la taille de la page est mauvais.
Question: quand l'utilisateur obtient l'URI http: // xxx / utilisateur? Page = 1 La réponse a-t-elle un lien dans la page suivante? page précédente? Sinon, ce n'est pas vraiment reposant.
Je suis plus inquiet que la charge utile impeccable est générée et que la bande passante soit gaspillée. Bien sûr, l'application ne s'écrasera pas, mais cela entraînera une charge inutile sur le backend de recherche et sur le bâtiment de l'intervention XML / JSON. Dans mon avis, la taille de l'envoi = 1000000 est plutôt étrange et est un accident ou malveillant. Bien sûr, les liens de pagination sont inclus :)
Comprendu - mais pour une personne qui effectue une exploitation minière de données ou d'autres actions nécessitant un ensemble de données volumineux, je peux le voir se produire. Honnêtement, je jetterais une mauvaise demande (400), avec un message d'erreur indiquant la taille maximale de la page. Renvoyer un certain nombre de articles définis sur le serveur se tournera vers l'utilisateur comme ils ont demandé 100 000 mais ont 200, ce qu'ils penseront probablement signifie que 200 articles ne sont pas disponibles.
Si vous retournez des liens de pagination suivants / précédents, il devrait être clair qu'il y a plus de données.
@Nate - Première règle de design, ne présumez jamais rien. Presque chaque fois que je vois un utilisateur confus, je vois un programmeur quelque part dire "c'est évident".