web services - standard - Servicios web RESTful y verbos HTTP
standard api restful (5)
¿Cuál es el conjunto mínimo de verbos HTTP que un servidor debe permitir que un servicio web se clasifique como RESTful?
¿Qué pasa si mi hoster no permite PUT y DELETE ?
¿Es esto realmente importante? ¿Puedo vivir feliz para siempre con solo GET y POST ?
Actualización: Gracias por las respuestas, la respuesta de Roger fue probablemente la mejor debido al vínculo con la entrevista de Bill Venners y Elliotte Rusty Harold. Ahora lo entiendo
Los navegadores web de hoy solo manejan GETS + POSTS. En Rails, por ejemplo, PUTS + DELETES se "falsifican" a través de campos de formulario ocultos.
A menos que su marco tenga alguna solución para "respaldar" PUTS + DELETES, no se preocupe por ellos por el momento.
Sí, puedes vivir sin PUT y DELETE.
Este artículo te dice por qué: http://www.artima.com/lejava/articles/why_put_and_delete.html
Si bien para los verdaderos RESTafrians esto puede ser una herejía, en el mundo real haces lo que puedes con lo que tienes. Sea lo más racional que pueda y tan consecuente con su propia convención como sea posible, pero definitivamente puede construir un buen sistema RESTful sin P y D.
rp
Si solo usa GET y POST, todavía es RESTful. Su servicio web solo puede hacer cosas que solo requieren GET o POST, así que está bien.
También puede usar X-Http-Verb-Override: DELETE inst. de HTTP DELETE. Esto también es útil para los clientes de Silverlight que no pueden cambiar los verbos HTTP y solo admiten GET y POST ...
REST permite romper la convención de protocolo si las implementaciones del protocolo están rotas (de modo que las únicas cosas no estándar que se hacen son para evitar las partes rotas de la implementación). Por lo tanto, dentro de REST se permite utilizar algún otro método para representar verbos generalmente no compatibles, como DELETE o PUT.
editar: Aquí hay una cita de Fielding, quien es el que creó y definió REST:
Una API REST no debe contener ningún cambio en los protocolos de comunicación además de completar o corregir los detalles de los bits de los protocolos estándar, como el método PATCH de HTTP o el campo del encabezado Link. Las soluciones provisionales para implementaciones rotas (como aquellos navegadores lo suficientemente estúpidos para creer que HTML define el conjunto de métodos de HTTP) deben definirse por separado, o al menos en apéndices, con la expectativa de que la solución eventualmente se vuelva obsoleta. [La falla aquí implica que las interfaces de recursos son específicas del objeto, no genéricas].