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

Después de leer mucho sobre las diferencias entre REST y SOAP, tuve la impresión de que REST es solo otra palabra para HTTP. ¿Alguien puede explicar qué funcionalidad agrega REST 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 como debe ser. Sin embargo, no estoy seguro de si esto merece un término propio, y ciertamente no entiendo el bombo a su alrededor.

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, GETy POST. La forma REST de hacerlo es utilizar todos los métodos del protocolo.

Por ejemplo, REST dicta el uso de DELETEpara borrar un documento (ya sea un archivo, estado, etc.) detrás de un URI, mientras que, con HTTP, usaría mal una GETo una POSTconsulta como ...product/?delete_id=22.

HTTP es un protocolo utilizado para la comunicación, generalmente utilizado 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 desee realizar, debe definir un recurso en el que generalmente solo realiza la operación CRUD, que es una tarea simple. para eso es muy conveniente usar 4 verbos usados ​​en el protocolo HTTP contra las 4 operaciones CRUD (Get for Read, POST es para CREATE, PUT es para UPDATE y DELETE es para DELETE). eso es diferente al concepto anterior de RPC (Remote Procedure Call), en el que tiene un conjunto de acciones que desea realizar como resultado de la llamada del usuario. si piensa, por ejemplo, en cómo describir un facebook como en una publicación, con RPC puede crear servicios llamados AddLikeToPost y RemoveLikeFromPost, y administrarlo junto con todos sus otros servicios relacionados con publicaciones FB, por lo que no necesitará crear especiales objeto para Me gusta. con REST tendrá un objeto Like que se administrará por separado con las funciones Eliminar y Crear. También significa que describirá una entidad separada en su base de datos. eso puede parecer una pequeña diferencia, pero trabajar de esa manera generalmente generarí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 (modelo) del objeto, a diferencia de RPC con el que normalmente tendría que agregar explícitamente mucha más lógica.

diseñar una aplicación RESTful suele ser mucho más difícil porque requiere que describas cosas complicadas de una manera simple. Describir todas las funcionalidades utilizando solo las funciones CRUD es complicado, pero después de hacerlo, su vida sería mucho más simple y encontrará que escribirá métodos mucho más cortos.

Una arquitectura REST más de restricción presente es no usar el contexto de sesión cuando se comunica con el cliente (sin estado), lo que significa que toda la información necesita entender quién es el cliente y qué quiere que se transmita 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 cuál es la página anterior y qué tipo de página deseas, el cliente tendría que decir "mi nombre es yuval, obtén me 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 "Consiga la próxima página" en lugar de "

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

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 importantes de REST que distinguen una aplicación RESTful de cualquier aplicación HTTP, diría que la restricción de "autodescripción" y la restricción de hipermedia (también conocida como Hypermedia como el motor del estado de la aplicación (HATEOAS)) el más importante.

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

La restricción de HATEOAS se trata de convertir su aplicación en una web 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.

Según tengo entendido, REST impone el uso de los comandos HTTP disponibles como estaban destinados a ser utilizados.

Por ejemplo, podría hacer:

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

Pero con descanso usaría el método de solicitud "DELETE", eliminando la necesidad del parámetro de consulta "método"

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

No exactamente...

http://en.wikipedia.org/wiki/Representational_State_Transfer

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 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 bien definida y preexistente 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 su contenido. Visto (con WSDL y UDDI) como uno de los tres estándares básicos de los servicios web, es el protocolo preferido para el intercambio de servicios web, pero de ninguna manera es el único; Los defensores de REST dicen que agrega una complejidad innecesaria.

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 = Transferencia de estado representativa

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:

No tiene estado, lo que significa que, idealmente, no se debe mantener ninguna 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 se identifica mediante el identificador de sesión pasado por el cliente.

Ventajas de la apatridia:

1. Los servicios web pueden tratar las llamadas de cada método por separado.
2. Los servicios web no necesitan mantener la interacción previa del cliente.
3. Esto a su vez simplifica el diseño de la aplicación.
4. 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:

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

Métodos HTTP admitidos por REST:

OBTENGA: / 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 Usado para crear recursos. Las llamadas múltiples deberían idealmente devolver resultados diferentes y deberían crear múltiples productos.

BORRAR: Se usa para eliminar recursos en el servidor.

CABEZA:

El método HEAD es idéntico a 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 requisitos asociados con un recurso, o las capacidades de un servidor, sin implicar una acción de recurso o iniciar una recuperación de recursos.

Respuestas HTTP

Vaya aquí para todas las respuestas .

Aquí hay algunos importantes: 200 - OK 3XX - Información adicional necesaria del cliente y redireccionamiento de URL 400 - Solicitud incorrecta
401 - No autorizado para acceder
403 - Prohibido
La solicitud fue válida, pero el servidor rechaza la acción. Es posible que el usuario no tenga los permisos necesarios para un recurso o que necesite una cuenta de algún tipo.

404 - No encontrado
El recurso solicitado no se pudo encontrar, pero puede estar disponible en el futuro. Se permiten solicitudes posteriores del cliente.

405 - Método no permitido No se admite un método de solicitud para 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 - Falla interna del servidor
502 - Error de puerta de enlace incorrecta

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. Rest es un protocolo para intercambiar cualquier mensaje (XML o JSON) que pueda usar HTTP para transportar esos mensajes.

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 REST API solo porque REST was inspired by WWW (world wide web) which largely used HTTPantes de que se definiera REST, por lo que es más fácil implementar el estilo REST API con HTTP.

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

1. La interacción entre el servidor y el cliente debe describirse solo a través de hipertexto.

2.El servidor y el cliente deben estar acoplados libremente y no hacer suposiciones el uno del otro. El cliente solo debe conocer el punto de entrada de recursos. El servidor debe proporcionar los datos de interacción en la respuesta.

3.El 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 lograr esto.

Para obtener más información, consulte estos enlaces:

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

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

De Usted no sabe 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 se creó para ser el protocolo ideal para seguir los principios y limitaciones 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.

Las API REST deben ser impulsadas por hipertexto

Desde el blog de Roy Fielding, aquí hay un conjunto de formas de verificar si está 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 un solo protocolo de comunicación, aunque su asignación exitosa a un protocolo determinado puede depender de la disponibilidad de metadatos, la elección de métodos, etc. En general, cualquier elemento del protocolo que use un URI para la identificación debe permitir cualquier esquema URI que se utilizará en aras 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, aparte de completar o corregir los detalles de bits no especificados de protocolos estándar, como el método PATCH de HTTP o el campo de encabezado de enlace. Las soluciones alternativas para implementaciones rotas (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. [La falla aquí implica que las interfaces de recursos son específicas del objeto, no genéricas.]
• Una API REST debería dedicar casi todo su esfuerzo descriptivo a definir los tipos de medios utilizados para representar los recursos y conducir el estado de la aplicación, o para definir nombres de relaciones extendidas y / o marcado habilitado para hipertexto para los tipos de medios estándar existentes. Cualquier esfuerzo dedicado a describir qué métodos usar en qué URI de interés debe definirse por completo dentro del alcance de las reglas de procesamiento para un tipo de medio (y, en la mayoría de los casos, ya definido por los tipos de medios existentes). [La falla aquí implica que la información fuera de banda impulsa la interacción en lugar del hipertexto].
• Una API REST no debe definir nombres de recursos fijos o jerarquías (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 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 de dominio, que es el equivalente orientado a datos al acoplamiento funcional de RPC].
• Una API REST nunca debe tener recursos "escritos" que sean significativos para el cliente. Los autores de las 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 representación actual y los nombres de relación estandarizados. [í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, se espera que cualquier cliente que pueda usar la API entienda). A partir de ese momento, todas las transiciones de estado de la aplicación deben ser conducidas por la selección del cliente de opciones proporcionadas por el servidor que están presentes en las representaciones recibidas o implicadas por la manipulación del usuario de esas representaciones. Las transiciones pueden estar determinadas (o limitadas por) el conocimiento del cliente sobre los tipos de medios y los mecanismos de comunicación de recursos, los cuales pueden mejorarse sobre la marcha (por ejemplo, código bajo demanda). [La falla aquí implica que la información fuera de banda está impulsando la interacción en lugar del hipertexto].