Comment puis-je gérer les limitations de longueur de chaîne de requête HTTP GET tout en voulant rester RESTful?

Question

Comme indiqué dans http://www.boutell.com/newfaq/misc/urllength.html, chaîne de requête HTTP, ont une durée limitée. Il peut être limité par le client (Firefox, IE, ...), le serveur (Apache, IIS, ...) ou de l'équipement de réseau (pare-feu applicatif, ...).

Aujourd'hui, je fais face à ce problème avec un formulaire de recherche. Nous avons développé un formulaire de recherche avec un grand nombre de domaines, et ce formulaire est envoyé au serveur une requête GET, donc je peux mettre en signet la page de résultat.

Nous avons tellement de domaines que notre chaîne de requête est de 1100 octets de long, et nous avons un pare-feu qui tombe requêtes HTTP GET avec plus de 1024 octets. Notre administrateur système nous recommande d'utiliser POST au lieu de cela, donc il n'y aura pas de limitation.

Bien sûr, POSTE de travail, mais j'ai vraiment l'impression d'une recherche, d'un GET et pas un POST. Donc, je pense que je vais passer en revue nos noms de champ afin d'assurer la chaîne de requête n'est pas trop long, et si je ne peux pas, je vais être pragmatique et de l'utilisation POST.

Mais est-il une faille dans la conception de services RESTful? Si nous avons limité la longueur dans la requête GET, comment puis-je faire pour envoyer de gros objets pour un séjour Reposant webservice? Par exemple, si j'ai un programme qui fait des calculs basés sur un fichier, et je tiens à donner un repos d'un webservice comme ceci: http://compute.com?content=<base64 file>. Cela ne marchera pas, parce que la chaîne de requête n'a pas la longueur illimitée.

Je suis un peu perplexe...

Answer 1

Spécification HTTP réellement conseille d'utiliser de POSTE lors de l'envoi de données à une ressource de calcul.

Votre recherche ressemble à un calcul, et non pas une ressource elle-même. Ce que vous pourriez faire si vous voulez toujours vos résultats de recherche pour être une ressource, c'est de créer un jeton de façon à identifier spécifiques le résultat des recherches et rediriger l'utilisateur de l'agent à cette ressource.

Vous pouvez ensuite supprimer les résultats de recherche des jetons après un certain laps de temps.

Exemple

POST /search
query=something&category=c1&category=c2&...

201 Created
Location: /search/01543164876

alors

GET /search/01543164876

200 Ok
... your results here...

De cette façon, les navigateurs et les procurations peuvent encore cache de résultats de recherche, mais vous présentez vos paramètres de requête à l'aide de POST.

Answer 2

En fonction de votre description, à mon humble avis, vous devriez utiliser un POST. POST est pour avoir les données sur le serveur et, dans certains cas, obtenir une réponse. Dans votre cas, vous faites une recherche (envoyer une requête au serveur) et obtenir le résultat de cette recherche (récupérer le résultat de la requête).

La définition de GET dit qu'il doit être utilisé pour récupérer une ressource. Par définition, le POST est de créer une nouvelle ressource. C'est exactement ce que vous faites: la création d'une ressource sur le serveur et de le récupérer! Même si vous n'avez pas stocker le résultat de recherche, vous avez créé un objet sur le serveur et récupéré. Comme PeterMmm previsouly dit, vous pouvez le faire avec un POST (de créer et de stocker le résultat de la requête) et ensuite utiliser un GET à la restauration de la requête, mais il est plus pratique de le faire seulement un POST et récupérer le résultat.

Espérons que cette aide! :)

Answer 3

REST est une manière de faire les choses, pas un protocole. Même si vous n'aimez pas postter quand il s'agit vraiment d'une opération GET, cela fonctionnera.

Si vous voulez / devez rester avec la définition "standard" de GET, POST, etc. que vous envisagez peut-être de POST une requête, cette requête sera stockée sur le serveur avec un identifiant de requête et demandera plus tard la requête avec GET par id.

Answer 4

Concernant votre exemple:http://compute.com?content={base64file}, je voudrais utiliser POST, parce que vous êtes téléchargement de "quelque chose" pour être calculé. Pour moi, ce "quelque chose" se sent plus comme une ressource, comme un simple paramètre.

En revanche, dans la recherche habituel je voudrais commencer à coller avec OBTENIR et de paramètres. Vous faites, il est donc beaucoup plus facile pour api-clients de tester et de jouer avec votre api. Faire de l'accès en lecture seule (ce qui, dans la plupart des cas, la majorité du trafic) aussi simple que possible!

Mais le dilemme de grandes chaînes de requête est valide, la limitation de l'OBTENIR. Ici, je voudrais aller pragmatique, aussi longtemps que vous n'avez pas touché de cette limite, aller avec elle et url-params. Cela fonctionne à 98% de la recherche-cas. Seulement si vous atteignez cette limite, et puis aussi introduire POST avec une charge utile (avec type mime Content-Type: application/x-www-form-urlencoded).

Avez-vous plus d'exemples du monde réel?

Answer 5

La confusion autour de GET est une limitation du navigateur. Si vous créez une interface RESTful pour une application A2A ou P2P, la longueur de votre GET n'est pas limitée.

Maintenant, si vous souhaitez utiliser un navigateur pour afficher votre interface RESTful (pendant le développement / le débogage), vous rencontrerez cette limite, mais il existe des outils pour contourner ce problème.