Je boulant une interface de repos sur une application existante et je suis curieux de savoir ce que la solution la plus appropriée consiste à traiter des ressources qui rendraient une quantité exorbitante de données si elles devaient être récupérées.
L'application est un système de feuille de temps existant et l'une des ressources est un ensemble de «créneaux horaires» d'un utilisateur.
Un exemple d'uri pour ces ressources est: J'ai lu beaucoup de questions relatives à la manière de fournir le filtrage de cette ressource pour récupérer un sous-ensemble et j'ai déjà un solution pour cela. Je veux savoir comment (ou si) je devrais faire face à la situation que l'émission de l'URI ci-dessus rendrait des mégaques de données de dizaines ou de centaines de milliers de lignes et prendraient une bonne quantité de ressource de serveur pour réagir réellement en premier lieu. EDIT: Pour être clair, j'ai filtré et fractionnement de la ressource mise en œuvre et avoir considéré la pagination sur d'autres ressources de collecte importantes. Je tiens à répondre de manière appropriée aux demandes qui n'ont pas de sens (et ont évidemment été demandée par un client construisant une URI).
J'ai trouvé le code http 413 qui concerne une entité de demande trop grande, mais pas une qui serait appropriée lorsque l'entité de réponse serait trop grande
4 Réponses :
Cela peut être trop faible d'une réponse, mais voici comment mon équipe l'a traitée. Des ressources importantes telles que celles sont nécessaires pour avoir les informations de filtrage supplémentaires fournies. Si les informations de filtrage ne sont pas là pour conserver la taille dans une plage spécifique, nous renvoyons une erreur interne (500) avec un message approprié pour indiquer que c'était un défaut d'utiliser correctement l'API reposante.
J'espère que cela aide.
HTTP 500 n'est généralement pas approprié pour un code d'erreur intentionnel. 500 devraient être utilisés lorsque le logiciel a échoué de manière inattendue ou a rencontré une condition d'exception. Au lieu de cela, il convient de renvoyer une mauvaise demande HTTP 400. Voir cette Stackoverflow POST .
Vous êtes libre de concevoir vos URI comme vous voulez encoder n'importe quel concept . Donc, selon vos utilisateurs (humains / machines), vous pouvez utiliser cela comme scission sur un niveau conceptuel basé sur un niveau conceptuel. sur votre espace ou votre domaine. Comme vous avez mentionné, vous avez probablement quelque chose comme ceci: une fois peut également limiter par les idées / concepts comme ci-dessus. Vous filtrez davantage en ajoutant des requêtes / utilisateurs / 44 / TIMESLOTS? JOUR = SIEMADIVES ET DOW = MON Faire usage ou concept, comme celui-ci limitera naturellement la taille de la réponse. Mais vous devez essayer de concevoir votre API Utiliser l'un des outils de repos - hypermédia et liens (voir aussi hateoas ) Lien vers la prochaine partie de votre hypermédia, utilisez" le morceau comme des concepts "que votre domaine comprend (pages, temps- emplacements). Pas besoin de télécharger des mégaoctes qui aussi
Hateoas .. lol. Merci @darrel Miller pour corriger la typo!
@Derick j'ai débattu de la modifier en réalité une contrainte hypertexte. Le consensus général semble être que l'acronyme haineux n'a aide à personne et à «contrainte d'hypertexte» est le terme privilégié.
Il existe de nombreuses pannes pour la ressource et les contraintes que je postule après l'URI du code orth / . J'ai aussi quelques contraintes de filtrage aussi. Je pense que la pièce du concept que je prendrai est 400 mauvaise demande est la meilleure réponse pour une demande directe à la ressource de base qui n'a pas vraiment de sens.
Pourquoi ne pas simplement servir un tas de liens sur la "ressource de base" avec la pagination? Quelle est votre ressource de base? (/ ou / temps de temps ou quelque chose de plus haut)
@Darrel Miller .. contrainte hypertext n'est pas aussi descriptive ni "cool" comme hateoas (pour les débutants que je suppose), mais étant donné le reste de la thèse de repos dans ce contexte c'est plus approprié. Je vais mettre à jour mon vocabulaire :) Merci pour la pointe.
Timeslots est une ressource de collection, pourquoi ne pas simplement activer la pagination sur cette ressource
voir ici: Pagination dans une application Web de repos
appeler obtenir sur la collection sans informations de page renvoie simplement la première page (avec une taille de page par défaut)
Dois-je simplement laisser le serveur se conformer à cette demande massive? Je pense que vous ne devriez pas, mais c'est à vous de décider, le serveur peut-il gérer de gros volumes? trouvez-vous cela une usesede valide?
Aha! USECASE est le mot magique. La question est également valable pour le scénario de pagination, est-ce une valeur upease? Sinon, pourquoi la peine de perdre du temps à la mettre en œuvre. Ce qui remonte à la question initiale, pourquoi discutons-nous de la mise en œuvre d'un point de terminaison qu'il ne semble pas être une upease et pourrait causer des problèmes si quelqu'un l'utilise.
Correct, il n'y a pas de cas d'utilisation pour cette ressource directement demandée sans filtre. Je veux simplement retourner une réponse appropriée à cette demande non valide.
@Alex 404 semble le plus logique pour moi. Le retour d'un 400 indiquerait le client que la demande a été mal formée et que si elles rendent la demande "correctement", cela rendrait une valeur.
@Darrel comparant maintenant 404 à 400, à partir d'un sens de données, la ressource existe mais n'a pas été demandée correctement. L'URI est valide et retournerait une ressource si une requête valide avait été fournie. c'est à dire. / User / 44 / TIMES ÉLIGNES BOTTES? DATE = 2011-03-26 est valide. Si nous ignorons que la requête a une signification et prenez l'URI d'inclure une requête également, vous êtes correct, l'URL demandée n'existe pas.
@Alex http://example.org/foo et http://example.org/foo?q=7 sont deux ressources différentes. Il s'agit d'une idée fausse commune que la ressource est identifiée par le segment de cheminement, mais ce n'est pas le cas. La chaîne de requête fait également partie de l'identifiant.
@Darrel confirmé conformément à la RFC3986, section 3.4: "Le composant de requête contient des données non hiérarchiques qui, ainsi que des données dans le composant chemin (section 3.3), sert à identifier une ressource dans le cadre du schéma de l'URI et de la nommage. autorité (le cas échéant). ".
Vous pouvez utiliser un en-tête de plage personnalisé - voir ou vous pouvez (comme d'autres que d'autres suggéraient) diviser votre ressource en ressources plus petites à différentes URL (représentant des sections ou des pages ou des versions filtrées autrement de la ressource d'origine).
Est-ce en fait un problème de retourner autant de données sur une telle demande? Ou essayez-vous simplement de protéger sa sécurité contre une récupération involontaire qui entraîne des ressources de serveur gaspillées et une bande passante?
Si la demande est idiote, alors n'implémentez pas de gestionnaire pour cette ressource et renvoyez une 404 si une personne construit à tort cette URI. ... puis battez-les sur la tête pour la construction d'URL :-)
@ Jeff-Hall Il n'y a pas de problème à revenir autant de données, il s'agit simplement d'une protection sûre contre la récupération inattendue que vous l'avez mentionnée.