Aparentemente, REST es solo un conjunto de convenciones sobre cómo usar HTTP . Me pregunto qué ventaja proporcionan estas convenciones. ¿Alguien sabe?
Respuestas:
No creo que obtenga una buena respuesta a esto, en parte porque nadie está de acuerdo en qué es REST . La página de wikipedia tiene muchas palabras de moda y poca explicación. Vale la pena echar un vistazo a la página de discusión solo para ver cuánta gente no está de acuerdo con esto. Sin embargo, hasta donde puedo decir, REST significa esto:
En lugar de tener direcciones URL setter y getter nombre aleatorio y el uso GETde todos los captadores y POSTpara todos los organismos, tratamos de tener las direcciones URL identifican los recursos, y luego usar las acciones de HTTP GET, POST, PUTy DELETEpara hacer cosas con ellos. Entonces en lugar de
GET /get_article?id=1
POST /delete_article id=1
Tu harías
GET /articles/1/
DELETE /articles/1/
Y luego POSTy PUTcorresponde a las operaciones "crear" y "actualizar" (pero nadie está de acuerdo en qué sentido).
Creo que los argumentos de almacenamiento en caché están equivocados, porque las cadenas de consulta son por lo general almacenan en caché, y además de que en realidad no necesitan para su uso. Por ejemplo, django hace que algo como esto sea muy fácil, y no diría que fue REST:
GET /get_article/1/
POST /delete_article/ id=1
O incluso simplemente incluya el verbo en la URL:
GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/
En ese caso GETsignifica algo sin efectos secundarios y POSTsignifica algo que cambia los datos en el servidor. Creo que esto es quizás un poco más claro y fácil, especialmente porque puedes evitar todo PUT-vs- POST. Además, puede agregar más verbos si lo desea, por lo que no está vinculado artificialmente a lo que ofrece HTTP. Por ejemplo:
POST /hide/article/1/
POST /show/article/1/
(¡O lo que sea, es difícil pensar en ejemplos hasta que sucedan!)
En conclusión, solo puedo ver dos ventajas:
synchronize("/articles/1/")o lo que sea. Esto depende en gran medida de su código.Sin embargo, creo que hay algunas desventajas bastante grandes:
PUTy cómo POSTson. En inglés significan cosas similares ("Voy a poner / publicar un aviso en el muro").En conclusión, diría: a menos que realmente quiera hacer un esfuerzo adicional, o si su servicio se asigna realmente bien a las operaciones CRUD, guarde REST para la segunda versión de su API.
Acabo de encontrar otro problema con REST: no es fácil hacer más de una cosa en una solicitud o especificar qué partes de un objeto compuesto desea obtener. Esto es especialmente importante en dispositivos móviles donde el tiempo de ida y vuelta puede ser significativo y las conexiones no son confiables. Por ejemplo, suponga que está recibiendo publicaciones en una línea de tiempo de Facebook. El modo REST "puro" sería algo así como
GET /timeline_posts // Returns a list of post IDs.
GET /timeline_posts/1/ // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....
Lo cual es un poco ridículo. La API de Facebook es una gran OMI, así que veamos qué hacen:
De forma predeterminada, la mayoría de las propiedades del objeto se devuelven cuando realiza una consulta. Puede elegir los campos (o conexiones) que desea devolver con el parámetro de consulta "campos". Por ejemplo, esta URL solo devolverá la identificación, el nombre y la imagen de Ben: https://graph.facebook.com/bgolub?fields=id,name,picture
No tengo idea de cómo harías algo así con REST, y si lo hicieras, si todavía contaría como REST. Sin embargo, ignoraría a cualquiera que intente decirte que no debes hacer eso (¡especialmente si la razón es "porque no es REST")!
/user/{id}, entonces no es tranquila. Considere: su navegador tiene que venir preprogramado sabiendo cómo obtener el HTML para una pregunta de stackoverflow página?
En pocas palabras, REST significa usar HTTP como debe ser.
Echa un vistazo a la disertación de Roy Fielding sobre REST . Creo que toda persona que esté haciendo desarrollo web debería leerlo.
Como nota, Roy Fielding es uno de los controladores clave detrás del protocolo HTTP, también.
Para nombrar algunos de los avances:
En pocas palabras: NINGUNO .
Siéntase libre de votar negativamente, pero sigo pensando que no hay beneficios reales sobre HTTP no REST. Todas las respuestas actuales son inválidas. Argumentos de la respuesta más votada actualmente:
Con REST necesita una capa de comunicación adicional para sus scripts del lado del servidor y del lado del cliente => en realidad es más complicado que el uso de HTTP no REST.
El almacenamiento en caché se puede controlar mediante encabezados HTTP enviados por el servidor. REST no agrega ninguna característica que falta en no REST.
REST no te ayuda a organizar las cosas. Te obliga a usar API compatible con la biblioteca del lado del servidor que estás usando. Puede organizar su aplicación de la misma manera (o mejor) cuando usa un enfoque que no es REST. Por ejemplo, ver Modelo-Vista-Controlador o enrutamiento MVC .
No es cierto del todo. Todo depende de qué tan bien organice y documente su aplicación. REST no mejorará mágicamente su aplicación.
En mi humilde opinión, la mayor ventaja que REST permite es la de reducir el acoplamiento cliente / servidor. Es mucho más fácil desarrollar una interfaz REST con el tiempo sin romper los clientes existentes.
Cada recurso tiene referencias a otros recursos, ya sea en jerarquía o enlaces, por lo que es fácil de navegar. Esto es una ventaja para el ser humano que desarrolla al cliente, lo que le evita consultar constantemente los documentos y ofrecer sugerencias. También significa que el servidor puede cambiar los nombres de los recursos unilateralmente (siempre que el software del cliente no codifique las URL).
Puede CURLAR en cualquier parte de la API o usar el navegador web para navegar por los recursos. Hace que la depuración y las pruebas de integración sean mucho más fáciles.
Le permite especificar acciones sin tener que buscar la redacción correcta. Imagínese si los captadores y establecedores de OOP no estuvieran estandarizados, y algunas personas lo usaran retrievey en su definelugar. Tendría que memorizar el verbo correcto para cada punto de acceso individual. Saber que solo hay un puñado de verbos disponibles contrarresta ese problema.
Si tiene GETun recurso que no existe, puede estar seguro de recibir un 404error en una API RESTful. Contraste con una API no RESTful, que puede regresar {error: "Not found"}envuelta en Dios sabe cuántas capas. Si necesita el espacio extra para escribir un mensaje al desarrollador en el otro lado, siempre puede usar el cuerpo de la respuesta.
Imagine dos API con la misma funcionalidad, una después de REST y la otra no. Ahora imagine los siguientes clientes para esas API:
Sosegado:
GET /products/1052/reviews
POST /products/1052/reviews "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10
HTTP:
GET /reviews?product_id=1052
POST /post_review?product_id=1052 "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10
Ahora piense en las siguientes preguntas:
Si la primera llamada de cada cliente funcionó, ¿qué tan seguro puede estar de que el resto también funcionará?
Hubo una actualización importante de la API que puede o no haber cambiado esos puntos de acceso. ¿Qué cantidad de documentos tendrás que volver a leer?
¿Puedes predecir el regreso de la última consulta?
Debe editar la revisión publicada (antes de eliminarla). ¿Puedes hacerlo sin consultar los documentos?
Recomiendo echar un vistazo a Cómo expliqué REST a mi esposa de Ryan Tomayko
Extracto del enlace waybackmaschine:
¿Qué tal un ejemplo? Eres profesor y quieres gestionar estudiantes:
Si los sistemas están basados en la web, entonces es probable que haya una URL para cada uno de los nombres involucrados aquí: student, teacher, class, book, room, etc. ... Si hubiera una representación legible por máquina para cada URL, sería trivial vincular nuevas herramientas al sistema porque toda esa información sería consumible de manera estándar. ... podría construir un sistema en todo el país que pudiera hablar con cada uno de los sistemas escolares individuales para recopilar los puntajes de los exámenes.
Cada uno de los sistemas obtendría información el uno del otro utilizando un simple HTTP GET. Si un sistema necesita agregar algo a otro sistema, usaría una POST HTTP. Si un sistema desea actualizar algo en otro sistema, utiliza un PUT HTTP. Lo único que queda por descubrir es cómo deberían verse los datos.
Sugeriría a todos los que estén buscando una respuesta a esta pregunta que pasen por esta "presentación de diapositivas" .
No podía entender qué es REST y por qué es tan genial, sus pros y sus contras, sus diferencias con SOAP, pero esta presentación de diapositivas fue tan brillante y fácil de entender, por lo que ahora es mucho más claro para mí que antes.
Almacenamiento en caché.
Hay otros beneficios más profundos de REST que giran en torno a la capacidad de evolución mediante acoplamiento flexible e hipertexto, pero los mecanismos de almacenamiento en caché son la razón principal por la que debería preocuparse por HTTP RESTful.
GET /get_article/19/y POST /update_articlesi el almacenamiento en caché es su preocupación? Todavía se puede hacer todo con sólo GETe POSTy creo que RESTsignifica "Uso GET, POST, PUTy DELETEsolamente." y no solo "No use cadenas de consulta". entonces lo que sugerí no sería REST. Por otra parte, nadie puede realmente estar de acuerdo con lo que REST es, así que lo estoy poniendo en un cubo con "Web 2.0".
Está escrito en la tesis de Fielding . Pero si no quieres leer mucho:
¿Es posible hacer todo solo con POST y GET? Sí, ¿es el mejor enfoque? ¿No porque? Porque tenemos métodos estándar. Si lo piensas de nuevo, sería posible hacer todo usando GET ... entonces, ¿por qué deberíamos molestarnos en usar POST? ¡Por los estándares!
Por ejemplo, hoy pensando en un modelo MVC, puede limitar su aplicación para responder solo a tipos específicos de verbos como POST, GET, PUT y DELETE. Incluso si debajo del capó todo se emula para POST y GET, ¿no tiene sentido tener verbos diferentes para diferentes acciones?
El descubrimiento es mucho más fácil en REST. Tenemos documentos WADL (similares a WSDL en los servicios web tradicionales) que lo ayudarán a anunciar su servicio al mundo. También puede usar los descubrimientos UDDI. Con HTTP POST y GET tradicionales, las personas pueden no conocer su solicitud de mensaje y los esquemas de respuesta para llamarlo.
Una ventaja es que podemos procesar documentos XML de forma no secuencial y datos XML desordenados de diferentes fuentes como el objeto InputStream, una URL, un nodo DOM ...
@Timmmm, sobre tu edición:
GET /timeline_posts // could return the N first posts, with links to fetch the next/previous N posts
Esto reduciría drásticamente la cantidad de llamadas
Y nada le impide diseñar un servidor que acepte parámetros HTTP para denotar los valores de campo que sus clientes pueden desear ...
Pero esto es un detalle.
Mucho más importante es el hecho de que no mencionó las enormes ventajas del estilo arquitectónico REST (escalabilidad mucho mejor, debido a la apatridia del servidor; disponibilidad mucho mejor, también debido a la apatridia del servidor; uso mucho mejor de los servicios estándar, como el almacenamiento en caché para ejemplo, cuando se usa un estilo arquitectónico REST; un acoplamiento mucho menor entre el cliente y el servidor, debido al uso de una interfaz uniforme; etc. etc.)
En cuanto a tu comentario
"No todas las acciones se asignan fácilmente a CRUD (crear, leer / recuperar, actualizar, eliminar)".
: un RDBMS también utiliza un enfoque CRUD (SELECCIONAR / INSERTAR / ELIMINAR / ACTUALIZAR), y siempre hay una forma de representar y actuar sobre un modelo de datos.
Sobre tu sentencia
"Puede que ni siquiera estés tratando con recursos de tipo de objeto"
: un diseño RESTful es, en esencia, un diseño simple, pero esto NO significa que diseñarlo sea simple. Ves la diferencia ? Tendrá que pensar mucho sobre los conceptos que su aplicación representará y manejará, lo que debe hacer por ella, si lo prefiere, para representar esto mediante recursos. Pero si lo hace, terminará con un diseño más simple y eficiente.
Los motores de búsqueda pueden ignorar las cadenas de consulta.