http - metodos - rest vs restful

¿Cuál es la diferencia entre HTTP y REST? (13)

Después de leer mucho sobre las diferencias entre REST y SOAP, tengo la impresión de que REST es solo una palabra más para HTTP. ¿Alguien puede explicar qué funcionalidad REST agrega a HTTP?

Nota : No estoy buscando una comparación de REST versus SOAP.

Actualización : Gracias por sus respuestas. Ahora me ha quedado claro que REST es solo un conjunto de reglas sobre cómo usar HTTP. Por lo tanto, publiqué un seguimiento sobre cuáles son las ventajas de estas convenciones .

Nota : ahora entiendo el significado de REST; como comenta Emil Ivanov , REST significa usar HTTP de la forma en que debe ser. Sin embargo, no estoy seguro de si esto merece un término propio, y ciertamente no me entusiasma.

Como lo entiendo, REST hace cumplir el uso de los comandos HTTP disponibles tal como estaban destinados a ser utilizados.

Por ejemplo, podría hacer:

GET http://example.com?method=delete&item=xxx

Pero con el resto utilizaría el método de solicitud "BORRAR", eliminando la necesidad del parámetro de consulta "método"

DELETE http://example.com?item=xxx

De No sabes la diferencia entre HTTP y REST.

Por lo tanto, la arquitectura REST y el protocolo HTTP 1.1 son independientes entre sí, pero el protocolo HTTP 1.1 fue creado para ser el protocolo ideal para seguir los principios y restricciones de REST. Una forma de ver la relación entre HTTP y REST es que REST es el diseño y HTTP 1.1 es una implementación de ese diseño.

HTTP es un protocolo de aplicación. REST es un conjunto de reglas que, cuando se siguen, le permiten crear una aplicación distribuida que tiene un conjunto específico de restricciones deseables.

Si está buscando las restricciones más significativas de REST que distinguen una aplicación REST de cualquier aplicación HTTP, yo diría que la restricción de "autodescripción" y la restricción de hipermedia (también conocida como Hipermedia como el Motor del Estado de la Aplicación (HATEOAS)) son el más importante.

La restricción de autodescripción requiere que una solicitud REST sea completamente autodescriptiva en la intención del usuario. Esto permite a los intermediarios (proxies y cachés) actuar sobre el mensaje de forma segura.

La restricción HATEOAS consiste en convertir su aplicación en una red de enlaces donde el estado actual del cliente se basa en su lugar en esa web. Es un concepto complicado y requiere más tiempo para explicarlo que el que tengo ahora.

HTTP es un protocolo de comunicaciones que transporta mensajes a través de una red. SOAP es un protocolo para intercambiar mensajes basados en XML que pueden usar HTTP para transportar esos mensajes. El resto es un protocolo para intercambiar cualquier mensaje (XML o JSON) que pueda usar HTTP para transportar esos mensajes.

HTTP es un protocolo que se usa para la comunicación, generalmente se usa para comunicarse con recursos de Internet o cualquier aplicación con un cliente de navegador web.

REST significa que el concepto principal que está utilizando al diseñar la aplicación es el Recurso: para cada acción que desea realizar, necesita definir un recurso en el que normalmente solo realiza la operación CRUD, que es una tarea sencilla. para eso es muy conveniente usar 4 verbos usados en el protocolo HTTP contra las operaciones 4 CRUD (Get for Read, POST es para CREATE, PUT es para UPDATE y DELETE es para DELETE). eso es a diferencia del antiguo concepto de RPC (llamada a procedimiento remoto), en el que tiene un conjunto de acciones que desea realizar como resultado de la llamada del usuario. Si piensa, por ejemplo, cómo describir un "me gusta" de Facebook en una publicación, con RPC podría crear servicios llamados AddLikeToPost y RemoveLikeFromPost, y administrarlo junto con todos los demás servicios relacionados con las publicaciones de FB, por lo que no necesitará crear Objeto para Me gusta. con REST tendrá un objeto Like que se administrará por separado con las funciones Delete y Create. También significa que describirá una entidad separada en su db. eso podría parecer una pequeña diferencia, pero trabajar así normalmente produciría un código mucho más simple y una aplicación mucho más simple. con ese diseño, la mayor parte de la lógica de la aplicación es obvia a partir de la estructura del objeto (modelo), a diferencia de RPC con el que normalmente tendría que agregar explícitamente mucha más lógica.

Diseñar una aplicación REST es generalmente mucho más difícil porque requiere que describas cosas complicadas de una manera simple. describir todas las funcionalidades usando solo las funciones de CRUD es complicado, pero después de hacer eso su vida sería mucho más simple y encontrará que escribirá métodos mucho más cortos.

Una restricción más de la arquitectura de REST presente es no usar el contexto de la sesión cuando se comunica con el cliente (sin estado), lo que significa que toda la información debe comprender quién es el cliente y lo que quiere se transmite con el mensaje web. Cada llamada a una función es autodescriptiva, no hay una conversación previa con el cliente a la que se pueda hacer referencia en el mensaje. por lo tanto, un cliente no podría decirle "dame la siguiente página", ya que no tienes una sesión para almacenar lo que es la página anterior y qué tipo de página quieres, el cliente tendría que decir "mi nombre es yuval, obtén Yo la página 2 de una publicación específica en un foro específico ". eso significa que un poco más de datos tendrían que transferirse en la comunicación, pero piense en la diferencia entre encontrar un error reportado en la función "Obtener la próxima página" en oposición a "Obtener la página 2 del Id. de pregunta 2190836 en el desbordamiento de pila".

Por supuesto, hay mucho más que eso, pero en mi opinión, son los conceptos principales en una cucharadita.

No exactamente...

REST

REST se describió inicialmente en el contexto de HTTP, pero no se limita a ese protocolo. Las arquitecturas RESTful pueden basarse en otros protocolos de la capa de aplicación si ya proporcionan un vocabulario rico y uniforme para aplicaciones basadas en la transferencia de un estado representativo significativo. Las aplicaciones RESTful maximizan el uso de la interfaz preexistente, bien definida y otras capacidades integradas proporcionadas por el protocolo de red elegido, y minimizan la adición de nuevas características específicas de la aplicación.

http://www.looselycoupled.com/glossary/SOAP

(Protocolo simple de acceso a objetos) El estándar para mensajes de servicios web. Basado en XML, SOAP define un formato de sobre y varias reglas para describir sus contenidos. Visto (con WSDL y UDDI) como uno de los tres estándares básicos de servicios web, es el protocolo preferido para intercambiar servicios web, pero de ninguna manera es el único; Los defensores de REST dicen que agrega complejidad innecesaria.

No, REST es la forma en que se debe usar HTTP .

Hoy solo usamos un poquito de los métodos del protocolo HTTP, a saber, GET y POST . La forma REST de hacerlo es usar todos los métodos del protocolo.

Por ejemplo, REST dicta el uso de DELETE para borrar un documento (ya sea un archivo, estado, etc.) detrás de un URI, mientras que, con HTTP, ...product/?delete_id=22 incorrectamente una consulta GET o POST como ...product/?delete_id=22 .

REST es una forma específica de abordar el diseño de grandes sistemas (como la web).

Es un conjunto de ''reglas'' (o ''restricciones'').

HTTP es un protocolo que intenta obedecer esas reglas.

REST no agrega ninguna funcionalidad específica a HTTP, pero es un estilo arquitectónico que se desarrolló junto con HTTP y generalmente utiliza HTTP para su protocolo de capa de aplicación.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style que puede usar HTTP, FTP u otros protocolos de comunicación, pero se usa ampliamente con HTTP.

REST implies a series of constraints about how Server and Client should interact . HTTP is a communication protocol with a given mechanism for server-client data transfer , se usa más comúnmente en la API REST solo porque REST was inspired by WWW (world wide web) which largely used HTTP antes de que se definiera REST, por lo que es más fácil implementar REST. Estilo API con HTTP.

There are three major constraints in REST (but there are more):

1. interacción entre el servidor y el cliente se debe describir solo mediante hipertexto.

2. servidor y el cliente deben estar ligeramente acoplados y no deben hacerse suposiciones entre sí. El cliente solo debe saber el punto de entrada del recurso. Los datos de interacción deben ser proporcionados por el servidor en la respuesta.

3. servidor no debe almacenar ninguna información sobre el contexto de la solicitud. Las solicitudes deben ser independientes e idempotentes (significa que si la misma solicitud se repite infinitamente, se recupera exactamente el mismo resultado)

Y HTTP es solo un protocolo de comunicación (una herramienta) que puede ayudar a lograrlo.

Para más información revisa estos enlaces:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST = Transferencia de Estado Representacional

REST es un conjunto de reglas que, cuando se siguen, le permiten crear una aplicación distribuida que tiene un conjunto específico de restricciones deseables.

REST es un protocolo para intercambiar cualquier mensaje (XML, JSON, etc.) que pueda usar HTTP para transportar esos mensajes.

caracteristicas:

Es sin estado, lo que significa que, idealmente, no se debe mantener una conexión entre el cliente y el servidor. Es responsabilidad del cliente pasar su contexto al servidor y luego el servidor puede almacenar este contexto para procesar la solicitud adicional del cliente. Por ejemplo, la sesión mantenida por el servidor está identificada por el identificador de sesión pasado por el cliente.

Ventajas de la apatridia:

Los servicios web pueden tratar las llamadas de cada método por separado.
Los servicios web no necesitan mantener la interacción previa del cliente.
Esto a su vez simplifica el diseño de la aplicación.
HTTP es en sí mismo un protocolo sin estado a diferencia de TCP y, por lo tanto, los servicios web RESTful funcionan a la perfección con los protocolos HTTP.

Desventajas de la apatridia:

Se debe agregar una capa adicional en forma de encabezado a cada solicitud para preservar el estado del cliente.
Por seguridad, necesitamos agregar una información de encabezado a cada solicitud.

Métodos HTTP soportados por REST:

GET: / string / someotherstring Es idempotente y lo ideal es que devuelva los mismos resultados cada vez que se realiza una llamada.

PUT: Igual que GET. Idempotente y se utiliza para actualizar recursos.

POST: debe contener una URL y un cuerpo Utilizado para crear recursos. Las llamadas múltiples idealmente deberían devolver resultados diferentes y deberían crear múltiples productos.

ELIMINAR: Se utiliza para eliminar recursos en el servidor.

CABEZA:

El método HEAD es idéntico al GET, excepto que el servidor NO DEBE devolver un cuerpo de mensaje en la respuesta. La metainformación contenida en los encabezados HTTP en respuesta a una solicitud HEAD DEBE ser idéntica a la información enviada en respuesta a una solicitud GET.

OPCIONES:

Este método permite al cliente determinar las opciones y / o los requisitos asociados con un recurso, o las capacidades de un servidor, sin implicar una acción de recursos o iniciar una recuperación de recursos.

Respuestas HTTP

Vaya aquí para todas las respuestas .

Éstos son algunos de los más importantes: 200 - OK 3XX - Información adicional necesaria del cliente y redirección de url 400 - Solicitud incorrecta
401 - Acceso no autorizado
403 - Prohibido
La solicitud era válida, pero el servidor está rechazando la acción. El usuario puede no tener los permisos necesarios para un recurso, o puede necesitar una cuenta de algún tipo.

404 No encontrado
El recurso solicitado no se pudo encontrar pero podría estar disponible en el futuro. Se permiten solicitudes posteriores por parte del cliente.

405 - Método no permitido Un método de solicitud no es compatible con el recurso solicitado; por ejemplo, una solicitud GET en un formulario que requiere que los datos se presenten a través de POST, o una solicitud PUT en un recurso de solo lectura.

404 - Solicitud no encontrada
500 - Fallo interno del servidor
502 - Error de pasarela incorrecto

Las API REST deben ser controladas por hipertexto

En el blog de Roy Fielding, aquí hay un conjunto de formas de verificar si estás creando una API HTTP o una API REST:

Diseñadores de API, tenga en cuenta las siguientes reglas antes de llamar a su creación una API REST:
Una API REST no debe depender de ningún protocolo de comunicación único, aunque su asignación exitosa a un protocolo dado puede depender de la disponibilidad de metadatos, la elección de métodos, etc. En general, cualquier elemento de protocolo que use un URI para la identificación debe permitir cualquier esquema de URI que se utilizará por el bien de esa identificación. [El fracaso aquí implica que la identificación no está separada de la interacción.]
Una API REST no debe contener ningún cambio en los protocolos de comunicación, además de completar o arreglar los detalles de bits no especificados de los protocolos estándar, como el método PATCH de HTTP o el campo del encabezado de enlace. Las soluciones alternativas para implementaciones fallidas (como los navegadores lo suficientemente estúpidos como para creer que HTML define el conjunto de métodos de HTTP) deben definirse por separado, o al menos en los apéndices, con la expectativa de que la solución eventualmente sea obsoleta. [El error aquí implica que las interfaces de recursos son específicas del objeto, no genéricas.]
Una API REST debe dedicar casi todo su esfuerzo descriptivo a definir los tipos de medios utilizados para representar los recursos y dirigir el estado de la aplicación, o definir nombres de relaciones extendidas y / o marcado de hipertexto para los tipos de medios estándar existentes. Cualquier esfuerzo dedicado a describir qué métodos usar en qué URI de interés se deben definir completamente dentro del alcance de las reglas de procesamiento para un tipo de medio (y, en la mayoría de los casos, ya está definido por los tipos de medios existentes). [El error aquí implica que la información fuera de banda está impulsando la interacción en lugar del hipertexto.]
Una API REST no debe definir nombres o jerarquías de recursos fijos (un acoplamiento obvio de cliente y servidor). Los servidores deben tener la libertad de controlar su propio espacio de nombres. En su lugar, permita que los servidores instruyan a los clientes sobre cómo construir los URI apropiados, como se hace en formularios HTML y plantillas de URI, definiendo esas instrucciones dentro de los tipos de medios y las relaciones de enlace. [La falla aquí implica que los clientes están asumiendo una estructura de recursos debido a la información fuera de banda, como un estándar específico del dominio, que es el equivalente orientado a los datos al acoplamiento funcional de RPC].
Una API REST nunca debe tener recursos "escritos" que sean significativos para el cliente. Los autores de especificaciones pueden usar tipos de recursos para describir la implementación del servidor detrás de la interfaz, pero esos tipos deben ser irrelevantes e invisibles para el cliente. Los únicos tipos que son significativos para un cliente son el tipo de medio de la representación actual y los nombres de las relaciones estandarizadas. [ídem]
Se debe ingresar una API REST sin conocimiento previo más allá del URI inicial (marcador) y un conjunto de tipos de medios estandarizados que sean apropiados para la audiencia prevista (es decir, cualquier cliente que pueda usar la API debe entenderlo). A partir de ese momento, todas las transiciones de estado de la aplicación deben estar dirigidas por la selección del cliente de las opciones proporcionadas por el servidor que están presentes en las representaciones recibidas o implícitas en la manipulación de esas representaciones por parte del usuario. Las transiciones pueden ser determinadas (o limitadas por) el conocimiento del cliente sobre los tipos de medios y los mecanismos de comunicación de recursos, y ambos pueden mejorarse sobre la marcha (por ejemplo, código a pedido). [El error aquí implica que la información fuera de banda está impulsando la interacción en lugar del hipertexto.]

REST no está necesariamente vinculado a HTTP . Los servicios web RESTful son solo servicios web que siguen una arquitectura RESTful.

What is Rest - 1- Client-server 2- Stateless 3- Cacheable 4- Layered system 5- Code on demand 6- Uniform interface