Llamar a un servicio RESTful con * muchos * parámetros

Question

Estamos diseñando una aplicación de iPhone que devolverá la llamada a un servicio RESTful que se ejecute en Tomcat. Necesitamos enviar muchos parámetros de consulta y haber excedido el máximo que el teléfono permitirá.

¿Sería RESTful utilizar una llamada PUT con los parámetros en el cuerpo, a pesar de la intención de no modificar el servidor? Un POST no parece correcto porque no es idempotente, mientras que un PUT es (y por lo tanto se asemeja más al comportamiento o a un GET).

Gracias.

Answer 1

Si lo desea RESTful, puede hacerlo de esta manera: PONGA los parámetros en el servidor (en la ubicación que elija), o puede PUBLICARlos y dejar que el servidor los coloque por usted. De cualquier manera, acaba de crear un recurso que contiene los parámetros que necesita. Luego envía un GET que se refiere a ese recurso en particular. Al responder a su GET, el servidor sabe por lo tanto dónde obtener su gran conjunto de parámetros. Eso sería RESTful.

Dicho esto, sin embargo, enviar dos solicitudes no es muy eficiente, si puede hacer lo mismo con una sola solicitud. Solo trataría de ser pragmático.

Considere esto: PUT le dice a los proxys que no deben almacenar en caché la respuesta, pero un reintento (por cualquier elemento de infraestructura a lo largo de la línea) es definitivamente posible, ya que es idempotente (como GET). ¿Qué te da GET por PUT? La respuesta puede ser almacenada en caché. Pero con esa gran cantidad de parámetros, supongo que la mayoría de las solicitudes serán únicas de todos modos, ¿no? Por lo tanto, el almacenamiento en caché no va a ofrecer mucho beneficio muy a menudo. Por lo tanto, usar PUT parece ser el pragmático y, por lo tanto, la elección correcta.

Answer 2

Viola el espíritu de REST, pero si funciona, sea pragmático.

Answer 3

usted tiene tres opciones que están conformes con el máximo http:

En primer lugar, usted tiene la opción de enviar a sus parametros comprimido de alguna manera para formar una URL más corta.

En segundo lugar, no hay nada sobre GET que diga que no puede enviar un mensaje-cuerpo en la solicitud, en lo que Content-Type o -Length elija. No todos los servidores admiten esto, pero sí el protocolo HTTP.

En tercer lugar, usted puede fijar los parámetros para un recurso /queries/, y tienen que responder con 201 Created y una nueva dirección URL (como /queries/78a65g82) en la cabecera Location respuesta, que el cliente llama a continuación GET en (varias veces, o incluso en Ranges , si eso es un beneficio) para recuperar el resultado.