REST vs RESTful vs servicio web "normal"

21

He leído un par de definiciones y debates sobre las aplicaciones REST y / o RESTful, pero todavía no entiendo el significado real de la misma.

Por lo general, trabajo con las aplicaciones que obtienen datos a través de GET o envían datos a través de POST a algún servicio web (generalmente un script PHP) que luego obtiene datos de la base de datos o escribe en la base de datos.

Ahora, ¿es esta una aplicación RESTful? Si no, ¿cuál sería una aplicación RESTful? ¿Cuál es la diferencia entre el concepto RESTful y el concepto con el que trabajé hasta ahora? Por favor explique a través de un ejemplo.

Además, alguien habla sobre REST y alguien sobre aplicaciones RESTful. Descubrí que el término REST se refiere al concepto teórico, mientras que RESTful se usa cuando hablamos de la aplicación específica. ¿Es correcto o hay diferencias reales entre las aplicaciones REST y RESTful?

— deviDave
fuente

1

Si puede construir todos sus Servlets para extraer información de los parámetros GET o POST SOLAMENTE (absolutamente nada guardado localmente antes de la llamada), entonces está aplicando REST correctamente. En otras palabras, el servidor desempeña el papel del modelo en MVC, ya que no tiene el control, sino que simplemente usa lo que se le da para realizar alguna tarea. Espero que eso lo explique un poco mejor.

— Neil

@Neil Estoy del otro lado: aplicación móvil. Es un cliente que utiliza el servicio web y se comunica con él a través de POST y GET. Todos los servicios web han sido creados por otra persona y todo lo que hice fue usarlos. Pero la terminología me confundió. Entonces, si estoy usando el canal HTTP y los objetos HttpGet / HttpPost, entonces estoy tratando con una aplicación RESTful, ¿verdad?

— deviDave

No necesariamente. No hay forma de saber si se trata de una aplicación RESTful si no sabe cómo se hace el servidor, ya que podría violar algunas restricciones. Dicho esto, probablemente sea RESTful si devuelve resultados consistentes.

— Neil

@Neil Oh, ya entiendo. RESTful se realiza en el servidor. Y si envío un objeto de publicación con una solicitud (no cada parámetro individualmente), entonces probablemente sea un enfoque REST. En cuanto a un cliente (aplicación móvil), no le importa si es REST o no, ya que la codificación es la misma. ¿Lo tengo bien?

— deviDave

2

RESTful es servidor y cliente, pero si solo puede ver al cliente, entonces solo puede saber si el cliente sigue las restricciones. Eso es todo lo que quise decir. Lo que quiero decir con REST es que, si necesitas iniciar sesión, publicas nombre de usuario y contraseña. El servidor valida el inicio de sesión y guarda la clave hash del usuario en la base de datos y la devuelve. Ahora, siempre que necesite realizar una operación que requiera inicio de sesión, siempre pasa la clave hash del usuario. El servidor "olvida" que inició sesión, pero utiliza el hash del usuario para validar su estado de inicio de sesión. Si no fuera RESTful, el servidor recordaría que ha iniciado sesión. ¿Comprende la diferencia?

— Neil

13

Los atributos clave de una aplicación RESTful son: Toda la comunicación se realiza a través de http GET, POST, PUT, DELETE Y todos los elementos se abordan a través de una URL estándar del formulario, http://your.site.com/salesapp/salesperson/0000001/detailses decir, solo una URL pura sin parámetros, etc. La URL identifica lo que GET , POST, PUT, DELETE identifica lo que quieres hacerle.

La razón principal para hacer esto es que automáticamente tiene un servicio sin estado que puede equilibrarse con la carga, fallar, etc., etc.

La simple simplicidad del esquema hace que la interfaz sea muy limpia, desacoplando totalmente al cliente de cualquier implementación particular de back-end.

— James Anderson
fuente

Oh, hasta ahora no he usado PUT o DELETE (las aplicaciones móviles generalmente solo hacen GET y POST), pero esto realmente se parece a lo que he hecho y estoy haciendo en este momento. Es solo que los clientes no usaron los términos REST *, sino más bien "servicio web" y "script php"

— deviDave

2

James, ¿podría explicar por qué se deben evitar los parámetros de consulta? Por ejemplo, ¿cómo expreso que quiero que los recursos se filtren de una manera particular sin introducir una jerarquía falsa?

— Gary Rowe

3

@GaryRowe: la URL (sin parámetros) identifica el recurso que desea manipular. Todavía puede tener parámetros, pero estos no se utilizan para identificar el recurso. Por ejemplo, un GET en un directorio (una URL que termina con /) debería devolver una lista de recursos en el directorio. Se puede usar un parámetro en la URL para especificar un filtro u orden de clasificación o algo así.

— Martin York

1

Gracias Loki. James podría querer editar su respuesta para reflejar eso, ya que parece que no está permitiendo que los parámetros de consulta se usen bajo ninguna circunstancia que pueda ser engañosa. En realidad, hay una observación interesante de que la lista de recursos en un directorio es en sí misma un recurso que expresa ese concepto.

— Gary Rowe

REST no requiere que la aplicación esté basada en URL ni requiere que tenga verbos como GET, POST, DELETE, etc. Sin embargo, para una aplicación web, URL es la única opción y los verbos mencionados anteriormente.

— Nawaz

6

REST significa Transferencia de Estado representativa. Si su software cumple con las Restricciones REST, entonces se considera RESTful.

Bien, ahora que descaradamente descarto de Wikipedia, ¿qué significa esto realmente? Efectivamente significa usar los comandos HTTP incorporados como GET, POST, PUT, DELETE y algunos otros más raros para comunicarse entre un cliente y un servidor.

Lo que estás haciendo parece una aplicación RESTFul. Sin embargo, hay una gran diferencia entre servicios web RESTFul bien diseñados y montones de basura. Por ejemplo, el código PHP en el otro extremo del GET podría ejecutar un cambio de estado, lo que se consideraría incorrecto ya que un GET se considera una operación de solo lectura. También hay diferencias sutiles entre cómo se usa POST (nuevo) y PUT (reemplazar).

El artículo de Wikipedia sobre esto es realmente bueno, así que me detendré aquí.

— Martijn Verburg
fuente

Hasta ahora, utilicé GET (HttpGet) para obtener contenido y POST (HttpPost) para ingresar / cambiar el contenido de una base de datos. Envié esto como parámetro a HttpPost y el script PHP en el servidor web convirtió estos parámetros en código SQL. ¿Es esta una aplicación RESTful? Estoy interesado en un concepto, no en qué tan bien se ha hecho el script PHP. No lo he logrado.

— deviDave

2

Investigaría el uso de PUT en el caso de que esté reemplazando contenido, es REST más idiomático que siempre usando POST.

— Martijn Verburg el

Sí, en ese caso usaría PUT.

— deviDave

+1 por notar que GET debe implementarse correctamente (es decir, es idempotente). Un error tan fundamental en los primeros días.

— Gary Rowe

@deviDave También es posible que desee examinar PATCH, que está diseñado para actualizar parte de un recurso. Como Martin señala acertadamente, PUT es para reemplazar todo el recurso.

— Gary Rowe

4

Antes de continuar, esta pregunta relacionada puede ayudarlo

La diferencia entre REST y RESTful es simplemente la semántica. REST es un estilo arquitectónico aplicado a una relación cliente-servidor. RESTful es simplemente una forma de decirle a sus clientes que usa REST.

Muchas aplicaciones web afirman ser RESTful, pero en realidad solo son parcialmente conformes con las Restricciones REST (como Martijn Verburg también ha mencionado en su respuesta). Solo los enumeraré aquí, pero le recomiendo encarecidamente que lea el artículo:

Servidor de cliente
Caché
Sistema de capas
Código bajo demanda (opcional)

Dado que usted menciona que trabaja en el lado del cliente, puede ser útil ver qué le dará y esperará una arquitectura REST como cliente de conexión. Aunque REST no es HTTP, es, con mucho, el protocolo más popular que admite lo que es REST, así que explicaré mi ejemplo al respecto.

Se espera que su cliente:

use verbos HTTP (por ejemplo, GET, POST, PUT, DELETE, OPTIONS, PATCH) para realizar operaciones relevantes
Ofrecer aceptar encabezados y comprender encabezados de tipo de contenido (por ejemplo, recibe algunos XML que nunca ha visto antes, pero puede usar un XSD referenciado para crear un modelo de dominio del lado del cliente para presentar a su usuario)
siga los enlaces ofrecidos en un Tipo de contenido que entienda (por ejemplo, haga que su usuario o su aplicación infieran que <link rel="pay" href="http://example.org/orders(1)/payment">en HTML expresa una transición de estado para crear un recurso de pago a través de una POST con un cuerpo que contiene algún XML que representa los detalles del pago como el número de tarjeta de crédito , cantidad y así sucesivamente)
reaccionar correctamente a la amplia gama de códigos de estado HTTP

Si hace lo anterior, entonces puede considerarse como un cliente REST, es posible que desee llamarlo una "aplicación RESTful", pero eso implicaría que está utilizando REST en el lado del cliente, lo cual es incorrecto, así que es mejor evitarlo el termino.

— Gary Rowe
fuente

3

RESTful significa que la interfaz es un conjunto de objetos que se pueden leer y actualizar (y posiblemente eliminar). Es decir, no hay consultas de parámetros múltiples (solo el parámetro es el objeto que desea leer) y solo hay un tipo de operación que cambia cualquier cosa en el servidor, la carga de un nuevo estado.

Estas limitaciones aseguran que todas las solicitudes sean idempotentes (enviarlas varias veces no tiene ningún efecto adicional al enviarlas una vez). Esto es importante, porque la red puede fallar en cualquier momento y no entregar ninguna solicitud o respuesta, y con las solicitudes idempotentes, simplemente la envía nuevamente y no tiene que realizar una recuperación complicada.

— Jan Hudec
fuente

Votación a favor del primer párrafo. Muy conciso ¡Gracias!

— deviDave

Una cosa más, para ver si acerté. Si yo (mi aplicación) es un cliente del servicio REST, ¿como cliente no caso si un servicio es RESTful o no, ya que mi codificación es siempre la misma (httpget, httppost, etc.)? ¿Este principio solo es importante para el propietario de un script / aplicación de servidor?

— deviDave

REST es una guía para diseñar la semántica de la interfaz. La tecnología subyacente es HTTP, ya sea que la interfaz sea RESTful o no (pero otras capas como XML-RPC o SOAP no son relevantes para las interfaces RESTful), por lo que siempre usa el mismo httpget, httppost, etc. Pero maneja las fallas de red de manera diferente.

— Jan Hudec

para agregar, SMTP es una interfaz RESTful, aunque utiliza diferentes verbos de GET, PUT, etc. y un protocolo subyacente diferente, el concepto es el mismo: envía comandos basados en verbos idempotentes a un servidor.

— gbjbaanb

No todas las solicitudes REST son idempotentes. Por ejemplo, la emisión de una POST varias veces generará muchos recursos nuevos.

— Gary Rowe

REST vs RESTful vs servicio web "normal" - ¿lo mismo o no?