¿Cómo se implementan formularios de “edición” de recursos de forma RESTful?

Question

Estamos intentando implementar una API REST para una aplicación que tenemos ahora.Queremos exponer capacidades de lectura/escritura para varios recursos utilizando la API REST.¿Cómo implementamos la parte "forma" de esto?Entiendo cómo exponer la "lectura" de nuestros datos creando URL RESTful que esencialmente funcionan como llamadas a métodos y devuelven los datos:

GET /restapi/myobject?param=object-id-maybe

...y se devuelve un documento XML que representa alguna estructura de datos.Bien.

Pero, normalmente, en una aplicación web, una "edición" implicaría dos solicitudes:uno para cargar la versión actual de los recursos y completar el formulario con esos datos, y otro para publicar los datos modificados.

Pero no entiendo cómo se haría lo mismo con los métodos HTTP a los que REST está asignado.Es un PUT ¿no?¿Alguien puede explicar esto?

(Consideración adicional:La UI se haría principalmente con AJAX)

-- Actualizar:Eso definitivamente ayuda.Pero, ¿todavía estoy un poco confundido acerca del lado del servidor?Obviamente, aquí no me refiero simplemente a archivos.En el servidor, el código que responde a las solicitudes debería filtrar el método de solicitud para determinar qué hacer con él.¿Es ese el "cambio" entre lecturas y escrituras?

Answer 1

Si envía los datos a través de HTML simple, está restringido a realizar un formulario basado en POST.El URI al que se envía la solicitud POST no debe Sea el URI del recurso que se está modificando.Debe PUBLICAR en un recurso de colección que AGREGUE un recurso recién creado cada vez (con el URI para el nuevo recurso en el Ubicación encabezado y un 202 código de estado) o POST a un recurso de actualización que actualiza un recurso con un URI proporcionado en el contenido de la solicitud (o encabezado personalizado).

Si está utilizando un objeto XmlHttpRequest, puede configurar el método en PUT y enviar los datos al URI del recurso.Esto también puede funcionar con formularios vacíos si el servidor proporciona un URI válido para el recurso aún inexistente.El primer PUT crearía el recurso (devolviendo 202).Los PUT posteriores no harán nada si son los mismos datos o modificarán el recurso existente (en cualquier caso, un 200 se devuelve a menos que ocurra un error).

Answer 2

Hay muchas alternativas diferentes que puedes utilizar.Una buena solución se proporciona en el wiki de microformatos y también ha sido referenciado por el equipo RESTful JSON.En realidad, lo más cerca que se puede llegar a un estándar.

 Operate on a Record

GET /people/1
    return the first record 
DELETE /people/1
    destroy the first record 
POST /people/1?_method=DELETE
    alias for DELETE, to compensate for browser limitations 

GET /people/1/edit
    return a form to edit the first record 
PUT /people/1
    submit fields for updating the first record 
POST /people/1?_method=PUT
    alias for PUT, to compensate for browser limitations 

Answer 3

Creo que es necesario separar los servicios de datos de la interfaz de usuario web.Al proporcionar servicios de datos, un sistema RESTful es totalmente apropiado, incluido el uso de verbos que los navegadores no pueden admitir (como PUT y DELETE).

Al describir una interfaz de usuario, creo que la mayoría de la gente confunde "RESTful" con "URL agradables y predecibles".No me preocuparía tanto una sintaxis de URL puramente RESTful cuando describe la interfaz de usuario web.

Answer 4

La carga debería ser simplemente una solicitud GET normal, y el guardado de datos nuevos debería ser una POST en la URL que actualmente tiene los datos...

Por ejemplo, cargue los datos actuales desde http://www.example.com/record/matt-s-example y luego, cambie los datos y PUBLICAR nuevamente en la misma URL con los nuevos datos.

Se podría utilizar una solicitud PUT al crear un nuevo registro (es decir,PONGA los datos en una URL que no existe actualmente), pero en la práctica simplemente PUBLICAR es probablemente un mejor enfoque para comenzar.