Appel d'un service RESTful avec * nombreux * paramètres

Question

Nous concevons une application iPhone qui rappellera un service RESTful s'exécutant dans Tomcat. Nous devons envoyer de nombreux paramètres de requête et avoir dépassé le maximum autorisé par le téléphone.

Serait-ce RESTful d'utiliser un appel PUT avec les paramètres dans le corps, même si l'intention de ne pas modifier le serveur? Un POST ne semble pas correct car il n'est pas idempotent, alors qu'un PUT est (et ressemble ainsi plus au comportement ou à un GET).

Merci.

Answer 1

Si vous le voulez RESTful, vous pouvez procéder de cette façon: METTEZ les paramètres sur le serveur (à l'emplacement de votre choix), ou vous pouvez les POSTER et laisser le serveur les placer pour vous. De toute façon, vous venez de créer une ressource qui contient les paramètres dont vous avez besoin. Ensuite, vous envoyez un GET se référant à cette ressource particulière. En répondant à votre GET, le serveur sait donc où obtenir son grand ensemble de paramètres. Ce serait RESTful. Cela dit, l'envoi de deux requêtes n'est pas très efficace, si vous pouvez faire la même chose avec une seule requête. J'essaierais juste d'être pragmatique. Considérez ceci: PUT dit aux proxies qu'ils ne devraient pas mettre en cache la réponse, mais une nouvelle tentative (par n'importe quel élément d'infrastructure le long de la ligne) est certainement possible, car elle est idempotente (tout comme GET). Qu'est-ce que GET vous donne sur PUT? La réponse peut être mise en cache. Mais avec ce grand nombre de paramètres, je suppose que la plupart des demandes seront uniques, n'est-ce pas? Donc, la mise en cache ne sera pas très rentable. Par conséquent, utiliser PUT semble être le pragmatique, et donc le bon choix.

Answer 2

Il viole l'esprit de REST, mais si cela fonctionne, soyez pragmatique.

Answer 3

Vous avez trois options qui sont au maximum avec HTTP: conforme

D'abord, vous avez la possibilité d'envoyer vos params comprimés d'une certaine façon pour former une URL plus courte.

Deuxièmement, il n'y a rien à propos de GET qui dit que vous ne pouvez pas envoyer un message-corps dans la demande, dans ce que Content-Type ou -Length vous choisissez. Tous les serveurs ne le supportent pas, mais le protocole HTTP lui-même le fait.

Troisièmement, vous pouvez afficher les paramètres à une ressource /queries/, et ont qui répondent avec 201 Created et une nouvelle URL (comme /queries/78a65g82) dans l'en-tête de réponse Location, que le client appelle ensuite GET sur (à plusieurs reprises, ou même dans Ranges , si c'est un avantage) pour récupérer le résultat.