2010-12-18 20 views
14

Sé PUT HTTP es una petición idempotente que almacenar algo en un URI específico, de acuerdo con la definición (citado de la rfc)¿Cómo se suele emitir una solicitud HTTP PUT?

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. 

Pero ¿cuál es la definición de 'entidad cerrada'? No me parece posible enviar los datos del formulario (como para la solicitud HTTP POST). ¿Qué pasa con el envío de la representación de la entidad a través de JSON/XML o en otros formatos de serialización?

En pocas palabras, ¿cómo se puede enviar una solicitud PUT HTTP a través de almacenar información/actualización a un URI específico, entonces?

+0

http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services – W55tKQbuRu28Q4xv

Respuesta

10

La entidad adjunta es la información de carga contenida en el cuerpo del mensaje HTTP (después de eliminar cualquier codificación de transferencia). Si tiene problemas para enviar el cuerpo del mensaje, es posible que haya olvidado incluir un Contenido -Levante encabezado: esa es una de las dos formas de indicar que el mensaje HTTP tiene un cuerpo.

PUT es la misma que la POST excepción de esta diferencia semántica: con el poste de la URI identifica un recurso que se encargará de la entidad, como un servlet. Con PUT, el URI identifica la entidad misma, por ejemplo, un archivo que se creará/reemplazará con los contenidos del cuerpo de la entidad.

10

En el descanso que tienen:

GET - retrieve resource 
POST - create new resource 
PUT - update existing resource 
DELETE - delete resource 

Así el verbo PUT se utiliza para actualizar un recurso existente en el servidor. Dependiendo del cliente, hay varias formas de enviar una solicitud PUT. Por ejemplo, con jQuery AJAX:

$.ajax({ 
    type: 'PUT', 
    url: '/products/123', 
    data: { name: 'new product name' } 
}); 
+0

pero ¿cómo se emite una solicitud HTTP PUT? es el que se publica en la siguiente pregunta de la manera correcta? http://stackoverflow.com/questions/2719610/should-i-allow-sending-complete-structures-when-using-put-for-updates-in-a-rest-a – Jeffrey04

+1

@ Jeffrey04, depende de lo que el servidor espera. En el ejemplo, muestra que es XML. Pero también podrías usar otros formatos.Le recomendaría que vea [este video sobre el uso de REST para SOA] (http://www.infoq.com/presentations/Using-REST-for-SOA). –

+0

http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ buena explicación de los diferentes usos de POST y PUT. Depende del uso de TI, no de la acción. –

2

Usted enviar un HTTP PUT donde el cuerpo es la 'entidad cerrado' que desea almacenar bajo la dirección URL solicitada. Muy similar a POST, es solo la semántica tal como se especifica en el RFC, que difiere.

+1

¿te importa incluir un ejemplo? gracias – Jeffrey04

+0

Quizás esté confundido al respecto: en realidad está enviando una solicitud HTTP POST; su navegador web no es compatible con PUT. Pase type = PUT en los datos del formulario para que su aplicación web (es decir, Rails) sepa qué hacer. –

+0

@Paul En realidad, estoy desarrollando un sitio api tranquilo a través de php (zend_framework), pero no sabía cómo se PUT en realidad (de ahí la pregunta) y no parece que el formulario de entrada deba/pueda usarse. Mi servidor web y la secuencia de comandos php son capaces de procesar solicitudes PUT aunque. – Jeffrey04

3

no estoy seguro si esta es la respuesta correcta, pero probablemente va a tratar

suponer después de emitir un HTTP GET a http://example.org/api/foo/1, consigo este

GET http://example.org/api/foo/1 
Accept: application/json 

Respuesta:

{ 
    "foo": "bar" 
} 

continuación, enviar una petición en poner

PUT http://example.org/api/foo/1 
{ 
    "foo": "baz" 
} 

siempre que la aplicación alojada en el punto final comprenda el formato que estoy enviando.

1

Si el Request-URI se refiere a un recurso ya existente, la entidad cerrado se debe considerar como una versión modificada de la que reside en el servidor de origen. Si el URI de solicitud no apunta a un recurso existente, y ese URI puede definirse como un recurso nuevo por el agente de usuario solicitante, el servidor de origen puede crear el recurso con ese URI.