¿Cuál es la carga útil de solicitud recomendada/efectiva para un método REST PUT?

Question

veo dos tipos de ejemplos en varios lugares. Uno de ellos utiliza campos de formulario como

rizo -X PONER -d "teléfono 123.456.7890 =" "http://127.0.0.1/services/rest/user/123"

y el otro utiliza un contenido XML como (alguna variación de) este

echo "< usuario> < id> 123 </id> < teléfono> 123.456.7890 </teléfono> </usuario>" | rizo -X PUT @ -d - "http://127.0.0.1/services/rest/user/"

Parece que el uso de los campos de formulario tiene la ventaja de la brevedad e identificar claramente la intención del cliente apuntando sólo los campos modificados, pero hace que sea difícil de abordar "más profunda "metadata"

Usando el contenido XML tiene una ventaja de ser más completa, pero la desventaja de la sobrecarga de averiguar qué campo el cliente está en realidad modificando (suponiendo que envían de nuevo todo el recurso con pequeñas modificaciones).

¿Hay una mejor práctica, o incluso una práctica más común?

Answer 1

En el segundo ejemplo de URL no se refiere a un recurso específico, por lo que en mi humilde opinión no es reparador.

Si arregla eso, la elección se reduce a la forma y codificación XML.

Si necesita datos estructurados y extensibles, entonces XML podría ser útil:

<phone type="work, mobile"><num>555-555</num><ext>123</ext></phone> 

pero no lo necesite:

phone=555-555&phone-ext=123&phone-type=work&phone-type=mobile 

Muchos de los usuarios de la API puede conseguir codificación XML mal, tienen problemas para comprender espacio de nombres direccionamiento indirecto, por lo que la codificación de la forma podría ser mejor para una amplia audiencia.

Answer 2

Buena pregunta! No sé de una mejor práctica específica o práctica común. Pero sí quiero señalar que la pregunta no es realmente sobre campos de formulario o XML, sino sobre representaciones parciales frente a representaciones completas. Usted ha descrito sucintamente las diferencias prácticas entre ellos. Un aspecto de la pregunta es quién tiene la responsabilidad de determinar qué ha cambiado: el cliente o el servidor.

Una opción híbrida sería algún tipo de formato en el que un cliente puede especificar qué exactamente ha cambiado, utilizando una sintaxis para apuntar a los metadatos "más profundo", como XPath o JSONpath, junto con el nuevo valor.

Answer 3

Podría ser algo así como JSON (P)? (No estoy seguro acerca de la sintaxis exacta):

$ echo '{user: {id: 123, phone: 123.456.7890}}' |\ 
> curl -X PUT -d @- 'http://127.0.0.1/services/rest/user/' 

O

$ echo '{phone: 123.456.7890}' |\ 
> curl -X PUT -d @- 'http://127.0.0.1/services/rest/user/123.json'