servicios restful que programacion lenguaje entre ejemplo diferencia http rest definition

http - restful - servicios rest java



¿Qué es exactamente la programación RESTful? (30)

¿Qué es exactamente la programación RESTful?

¿Qué es REST?

REST significa Representational State Transfer. (A veces se deletrea "ReST"). Se basa en un protocolo de comunicaciones sin caché, cliente-servidor, almacenable en caché, y en casi todos los casos, se utiliza el protocolo HTTP.

REST es un estilo de arquitectura para diseñar aplicaciones en red. La idea es que, en lugar de utilizar mecanismos complejos como CORBA, RPC o SOAP para conectarse entre máquinas, se utiliza HTTP simple para hacer llamadas entre máquinas.

En muchos sentidos, la propia World Wide Web, basada en HTTP, puede verse como una arquitectura basada en REST. Las aplicaciones RESTful utilizan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, hacer consultas) y eliminar datos. Por lo tanto, REST utiliza HTTP para las cuatro operaciones CRUD (Crear / Leer / Actualizar / Eliminar).

REST es una alternativa liviana a mecanismos como RPC (llamadas a procedimientos remotos) y servicios web (SOAP, WSDL, et al.). Más adelante, veremos cuánto más simple es REST.

A pesar de ser simple, REST tiene todas las funciones; Básicamente, no puede hacer nada en Servicios Web que no se pueda hacer con una arquitectura RESTful. REST no es un "estándar". Nunca habrá una recomendación W3C para REST, por ejemplo. Y si bien hay marcos de programación REST, trabajar con REST es tan simple que a menudo se puede "enrollar" con las funciones estándar de la biblioteca en lenguajes como Perl, Java o C #.

Una de las mejores referencias que encontré cuando trato de encontrar el simple significado real de descansar.

http://rest.elkstein.org/

REST es un estilo arquitectónico basado en estándares web y el protocolo HTTP (introducido en 2000).

En una arquitectura basada en REST, todo es un recurso (Usuarios, Pedidos, Comentarios). Se accede a un recurso a través de una interfaz común basada en los métodos estándar de HTTP (GET, PUT, PATCH, DELETE, etc.).

En una arquitectura basada en REST, usted tiene un servidor REST que proporciona acceso a los recursos. Un cliente REST puede acceder y modificar los recursos REST.

Cada recurso debe soportar las operaciones comunes de HTTP. Los recursos se identifican mediante ID globales (que suelen ser URI).

REST permite que los recursos tengan diferentes representaciones, por ejemplo, texto, XML, JSON, etc. El cliente REST puede solicitar una representación específica mediante el protocolo HTTP (negociación de contenido).

Métodos HTTP:

Los métodos PUT, GET, POST y DELETE se utilizan típicamente en arquitecturas basadas en REST. La siguiente tabla da una explicación de estas operaciones.

  • GET define un acceso de lectura del recurso sin efectos secundarios. El recurso nunca se cambia a través de una solicitud GET, por ejemplo, la solicitud no tiene efectos secundarios (idempotent).
  • PUT crea un nuevo recurso. También debe ser idempotente.
  • ELIMINAR elimina los recursos. Las operaciones son idempotentes. Se pueden repetir sin dar lugar a resultados diferentes.
  • POST actualiza un recurso existente o crea un nuevo recurso.

¿Qué es REST?

REST en palabras oficiales, REST es un estilo arquitectónico basado en ciertos principios que utilizan los fundamentos actuales de "Web". Hay 5 fundamentos básicos de la web que se aprovechan para crear servicios REST.

  • Principio 1: Todo es un recurso En el estilo de arquitectura REST, los datos y la funcionalidad se consideran recursos y se accede a ellos mediante identificadores uniformes de recursos (URI), generalmente enlaces en la Web.
  • Principio 2: cada recurso se identifica mediante un identificador único (URI)
  • Principio 3: Utilice interfaces simples y uniformes
  • Principio 4: La comunicación se hace por representación
  • Principio 5: Ser apátrida

Es la programación donde la arquitectura de su sistema se ajusta al ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm presenta Roy Fielding en su tesis . Dado que este es el estilo arquitectónico que describe la web (más o menos), muchas personas están interesadas en ella.

Respuesta extra: No. A menos que esté estudiando arquitectura de software como académico o diseñando servicios web, realmente no hay razón para haber escuchado el término.

Esto es lo que podría parecer.

Crea un usuario con tres propiedades:

POST /user fname=John&lname=Doe&age=25

El servidor responde:

200 OK Location: /user/123

En el futuro, puede recuperar la información del usuario:

GET /user/123

El servidor responde:

200 OK <fname>John</fname><lname>Doe</lname><age>25</age>

Para modificar el registro ( lname y age permanecerán sin cambios):

PATCH /user/123 fname=Johnny

Para actualizar el registro (y, en consecuencia, lname y age serán NULL):

PUT /user/123 fname=Johnny

La programación RESTful trata de:

  • recursos identificados por un identificador persistente: los URI son la opción ubicua del identificador en estos días
  • los recursos que se manipulan utilizando un conjunto común de verbos: los métodos HTTP son el caso más común: los venerables Create , Retrieve , Update , Delete convierten en POST , GET , PUT y DELETE . Pero REST no se limita a HTTP, es solo el transporte más utilizado en este momento.
  • La representación real recuperada para un recurso depende de la solicitud y no del identificador: use Aceptar encabezados para controlar si desea que XML, HTTP o incluso un objeto Java represente el recurso
  • Mantener el estado en el objeto y representar el estado en la representación.
  • Representación de las relaciones entre los recursos en la representación del recurso: los enlaces entre los objetos se incrustan directamente en la representación.
  • las representaciones de recursos describen cómo se puede usar la representación y bajo qué circunstancias se debe descartar / repasar de manera consistente: uso de encabezados HTTP Cache-Control

El último es probablemente el más importante en términos de consecuencias y efectividad general de REST. En general, la mayoría de las discusiones REST parecen centrarse en HTTP y su uso desde un navegador y lo que no. Entiendo que R. Fielding acuñó el término cuando describió la arquitectura y las decisiones que conducen a HTTP. Su tesis es más sobre la arquitectura y la capacidad de almacenamiento en caché de los recursos que sobre HTTP.

Si está realmente interesado en lo que es una arquitectura REST y por qué funciona, lea su tesis unas cuantas veces y lea todo el tema, ¡ no solo el Capítulo 5! A continuación, ver por qué funciona el DNS . Lea acerca de la organización jerárquica del DNS y cómo funcionan las referencias. Luego lee y considera cómo funciona el almacenamiento en caché de DNS. Finalmente, lea las especificaciones HTTP ( RFC2616 y RFC3040 en particular) y considere cómo y por qué el almacenamiento en caché funciona de la manera en que lo hace. Eventualmente, sólo hará clic. La revelación final para mí fue cuando vi la similitud entre DNS y HTTP. Después de esto, la comprensión de por qué SOA y las interfaces de paso de mensajes son escalables comienza a hacer clic.

Creo que el truco más importante para comprender la importancia de la arquitectura y las implicaciones de rendimiento de las arquitecturas RESTful y Shared Nothing es evitar quedar atrapado en la tecnología y los detalles de la implementación. Concéntrese en quién posee los recursos, quién es responsable de crearlos / mantenerlos, etc. Luego piense en las representaciones, los protocolos y las tecnologías.

La respuesta es muy simple, hay una disertación escrita por Roy Fielding.] 1 En esa disertación él define los principios REST. Si una aplicación cumple con todos esos principios, entonces esa es una aplicación REST.

roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven Después de eso, el término RESTful se agotó también. Hoy en día estamos hablando de las API web y las API de hipermedia , porque la mayoría de las llamadas aplicaciones REST no cumplieron con la parte HATEOAS de la restricción de interfaz uniforme.

Las restricciones REST son las siguientes:

  1. arquitectura cliente-servidor

    Por lo tanto, no funciona con, por ejemplo, sockets PUB / SUB, se basa en REQ / REP.

  2. comunicación sin estado

    Entonces el servidor no mantiene los estados de los clientes. Esto significa que no puede usar un servidor de almacenamiento de sesión lateral y tiene que autenticar cada solicitud. Sus clientes posiblemente envíen encabezados de autenticación básicos a través de una conexión encriptada. (Por aplicaciones grandes es difícil mantener muchas sesiones).

  3. uso de caché si puedes

    Así que no tienes que atender las mismas solicitudes una y otra vez.

  4. Interfaz uniforme como contrato común entre cliente y servidor.

    El contrato entre el cliente y el servidor no es mantenido por el servidor. En otras palabras, el cliente debe estar desacoplado de la implementación del servicio. Puede alcanzar este estado utilizando soluciones estándar, como el estándar IRI (URI) para identificar recursos, el estándar HTTP para intercambiar mensajes, tipos MIME estándar para describir el formato de serialización del cuerpo, metadatos (posiblemente vocabs RDF, microformatos, etc.) para Describe la semántica de las diferentes partes del cuerpo del mensaje. Para desacoplar la estructura IRI del cliente, debe enviar hipervínculos a los clientes en formatos de hipermedia como (HTML, JSON-LD, HAL, etc.). Por lo tanto, un cliente puede usar los metadatos (posiblemente las relaciones de enlace, los vocabs RDF) asignados a los hipervínculos para navegar por la máquina de estados de la aplicación a través de las transiciones de estado adecuadas para lograr su objetivo actual.

    Por ejemplo, cuando un cliente desea enviar un pedido a una tienda web, debe verificar los hipervínculos en las respuestas enviadas por la tienda web. Al revisar los enlaces, se encuentra uno descrito en http://schema.org/OrderAction . El cliente conoce el vocabulario de schema.org, por lo que entiende que al activar este hipervínculo enviará el pedido. Por lo tanto, activa el hipervínculo y envía un mensaje POST https://example.com/api/v1/order con el cuerpo apropiado. Después de eso, el servicio procesa el mensaje y responde con el resultado con el encabezado de estado HTTP adecuado, por ejemplo, 201 - created por éxito. Para anotar mensajes con metadatos detallados, la solución estándar es utilizar un formato RDF, por ejemplo, JSON-LD con un vocabulario REST, por ejemplo, Hydra y vocabularios específicos del dominio como schema.org o cualquier otro vocabulario de datos vinculados y tal vez un vocabulario específico para aplicaciones personalizadas necesario. Ahora bien, esto no es fácil, es por eso que la mayoría de las personas utilizan HAL y otros formatos simples que generalmente proporcionan solo un vocabulario REST, pero no soporte de datos vinculados.

  5. construir un sistema en capas para aumentar la escalabilidad

    El sistema REST está compuesto por capas jerárquicas. Cada capa contiene componentes que utilizan los servicios de los componentes que se encuentran en la siguiente capa a continuación. Así podrás agregar nuevas capas y componentes sin esfuerzo.

    Por ejemplo, hay una capa de cliente que contiene los clientes y debajo de ella hay una capa de servicio que contiene un solo servicio. Ahora puede agregar un caché del lado del cliente entre ellos. Después de eso, puede agregar otra instancia de servicio y un equilibrador de carga, y así sucesivamente ... El código de cliente y el código de servicio no cambiarán.

  6. Código a pedido para ampliar la funcionalidad del cliente.

    Esta restricción es opcional. Por ejemplo, puede enviar un analizador para un tipo de medio específico al cliente, y así sucesivamente ... Para hacer esto, es posible que necesite un sistema de cargador de complementos estándar en el cliente, o su cliente estará acoplado a la solución del cargador de complementos .

Las restricciones REST dan como resultado un sistema altamente escalable en el que los clientes se desacoplan de las implementaciones de los servicios. Por lo tanto, los clientes pueden ser reutilizables, en general como los navegadores en la web. Los clientes y los servicios comparten los mismos estándares y vocabularios, por lo que pueden entenderse a pesar del hecho de que el cliente no conoce los detalles de implementación del servicio. Esto hace posible crear clientes automatizados que pueden encontrar y utilizar los servicios REST para lograr sus objetivos.A largo plazo, estos clientes pueden comunicarse entre sí y confiar entre sí en las tareas, al igual que los humanos. Si agregamos patrones de aprendizaje a dichos clientes, entonces el resultado será uno o más AI utilizando la red de máquinas en lugar de un solo parque de servidores. Así que al final el sueño de Berners Lee: la web semántica y la inteligencia artificial serán realidad. Así que en 2030 terminamos terminados por el Skynet. Hasta entonces ... ;-)

Pido disculpas si no estoy respondiendo la pregunta directamente, pero es más fácil entender todo esto con ejemplos más detallados. Fielding no es fácil de entender debido a toda la abstracción y la terminología.

Hay un ejemplo bastante bueno aquí:

Explicando REST e hipertexto: Spam-E the Spam Cleaning Robot

Y aún mejor, aquí hay una explicación clara con ejemplos simples (el powerpoint es más completo, pero puede obtener la mayor parte en la versión html):

http://www.xfront.com/REST.ppt o http://www.xfront.com/REST.html

Después de leer los ejemplos, pude ver por qué Ken está diciendo que REST está controlado por hipertexto. Sin embargo, no estoy realmente seguro de que tenga razón, porque ese / usuario / 123 es un URI que apunta a un recurso, y no me queda claro que sea RETROVISTO solo porque el cliente lo sepa "fuera de banda".

Ese documento de Xfront explica la diferencia entre REST y SOAP, y esto también es muy útil. Cuando Fielding dice: " roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven ", está claro que RPC no es REST, por lo que es útil ver las razones exactas de esto. (SOAP es un tipo de RPC).

REST está utilizando los diversos métodos HTTP (principalmente GET / PUT / DELETE) para manipular los datos.

En lugar de utilizar una URL específica para eliminar un método (por ejemplo, /user/123/delete ), enviaría una solicitud DELETE a la URL /user/[id] , para editar un usuario, para recuperar la información de un usuario que envíe una solicitud GET para /user/[id]

Por ejemplo, en su lugar, un conjunto de URL que pueden parecerse a algunos de los siguientes ...

GET /delete_user.x?id=123 GET /user/delete GET /new_user.x GET /user/new GET /user?id=1 GET /user/id/1

Usas los "verbos" HTTP y tienes ...

GET /user/2 DELETE /user/2 PUT /user

Un gran libro sobre REST es REST en la práctica .

Las lecturas roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven son ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm y las roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Consulte el artículo de Martin Fowlers, el Modelo de Madurez de Richardson (RMM) para obtener una explicación de lo que es un servicio RESTful.

Para ser RESTful, un Servicio debe cumplir con la Hipermedia como el Motor del Estado de la Aplicación. (HATEOAS) , es decir, debe alcanzar el nivel 3 en la RMM, lea el artículo para obtener detalles o las diapositivas de qcon talk .

La restricción HATEOAS es un acrónimo de Hypermedia como el Motor del estado de la aplicación. Este principio es el diferenciador clave entre un REST y la mayoría de las otras formas de sistema de servidor de cliente.

...

Un cliente de una aplicación RESTful solo necesita conocer una única URL fija para acceder a ella. Todas las acciones futuras deben ser detectables dinámicamente desde los enlaces de hipermedia incluidos en las representaciones de los recursos que se devuelven desde esa URL. También se espera que los tipos de medios estandarizados sean entendidos por cualquier cliente que pueda usar una API RESTful. (De Wikipedia, la enciclopedia libre)

REST Litmus Test para Web Frameworks es una prueba de madurez similar para web frameworks.

Acercarse a REST puro: Aprender a amar HATEOAS es una buena colección de enlaces.

REST versus SOAP para la nube pública analiza los niveles actuales de uso de REST.

REST y el control de versiones analizan la extensibilidad, el control de versiones, la evolución, etc. a través de la modificabilidad

Veo un montón de respuestas que dicen que poner todo sobre el usuario 123 en el recurso "/ user / 123" es REST.

Roy Fielding, quien acuñó el término, dice que las roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven . En particular, "Una API REST no debe definir nombres de recursos fijos o jerarquías".

Entonces, si su ruta "/ user / 123" está codificada en el cliente, no es realmente REST. Un buen uso de HTTP, tal vez, tal vez no. Pero no es REST. Tiene que venir del hipertexto.

Yo diría que la programación REST sería sobre la creación de sistemas (API) que sigan el estilo arquitectónico REST.

Encontré este tutorial fantástico, breve y fácil de entender sobre REST por el Dr. M. Elkstein y citando la parte esencial que respondería a su pregunta en su mayor parte:

http://rest.elkstein.org/

REST es un estilo de arquitectura para diseñar aplicaciones en red. La idea es que, en lugar de utilizar mecanismos complejos como CORBA, RPC o SOAP para conectarse entre máquinas, se utiliza HTTP simple para hacer llamadas entre máquinas.

  • En muchos sentidos, la propia World Wide Web, basada en HTTP, puede verse como una arquitectura basada en REST.

Las aplicaciones RESTful utilizan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, hacer consultas) y eliminar datos. Por lo tanto, REST utiliza HTTP para las cuatro operaciones CRUD (Crear / Leer / Actualizar / Eliminar).

No creo que debas sentirte estúpido por no escuchar acerca de REST fuera de ..., ¡estaría en la misma situación !; las respuestas a esta otra pregunta SO sobre por qué REST está creciendo ahora podría aliviar algunos sentimientos.

RESTful programación de la API RESTful (transferencia de estado representativa) está escribiendo aplicaciones web en cualquier lenguaje de programación siguiendo los 5 principios básicos de estilo de arquitectura de software :

  1. Recurso (datos, información).
  2. Identificador global único (todos los recursos son únicos identificados por URI ).
  3. Interfaz uniforme : use una interfaz simple y estándar (HTTP).
  4. Representación: todas las comunicaciones se realizan por representación (por ejemplo, XML / JSON )
  5. Stateless (cada solicitud ocurre en completo aislamiento, es más fácil almacenar en caché y equilibrar la carga)

En otras palabras, está escribiendo aplicaciones de red punto a punto simples a través de HTTP que utilizan verbos como GET, POST, PUT o DELETE mediante la implementación de la arquitectura RESTful que propone la estandarización de la interfaz que expone cada "recurso". No es nada que usar las características actuales de la web de una manera simple y efectiva (arquitectura altamente exitosa, probada y distribuida). Es una alternativa a mecanismos más complejos como SOAP , CORBA y RPC .

La programación REST se ajusta al diseño de la arquitectura web y, si se implementa correctamente, le permite aprovechar al máximo la infraestructura web escalable.

Hablar es más que simplemente intercambiar información . Un protocolo está realmente diseñado para que no haya que hablar. Cada parte sabe cuál es su trabajo particular porque está especificado en el protocolo. Los protocolos permiten el intercambio de información pura a expensas de tener cambios en las acciones posibles. Hablar, por otro lado, permite que una parte pregunte qué otras acciones se pueden tomar de la otra parte. Incluso pueden hacer la misma pregunta dos veces y obtener dos respuestas diferentes, ya que el estado de la otra parte puede haber cambiado en el ínterin. Hablar es arquitectura REST . La tesis de Fielding especifica la arquitectura que uno tendría que seguir si uno quisiera permitir que las máquinas hablaran entre sí en lugar de simplementecomunicarse .

REST es el principio arquitectónico subyacente de la web. Lo sorprendente de la web es el hecho de que los clientes (navegadores) y los servidores pueden interactuar de forma compleja sin que el cliente sepa de antemano el servidor y los recursos que alberga. La restricción clave es que el servidor y el cliente deben estar de acuerdo con los medios utilizados, que en el caso de la web es HTML .

Una API que se adhiere a los principios de REST no requiere que el cliente sepa nada sobre la estructura de la API. Más bien, el servidor debe proporcionar cualquier información que el cliente necesite para interactuar con el servicio. Un formulario HTML es un ejemplo de esto: el servidor especifica la ubicación del recurso y los campos requeridos. El navegador no sabe de antemano dónde enviar la información y no sabe de antemano qué información enviar. Ambas formas de información son enteramente suministradas por el servidor. (Este principio se llama HATEOAS : Hipermedia como el motor del estado de la aplicación ).

Entonces, ¿cómo se aplica esto a HTTP y cómo se puede implementar en la práctica? HTTP está orientado alrededor de verbos y recursos. Los dos verbos en uso general son GET y POST, que creo que todos reconocerán. Sin embargo, el estándar HTTP define varios otros como PUT y DELETE. Estos verbos se aplican a los recursos, de acuerdo con las instrucciones proporcionadas por el servidor.

Por ejemplo, imaginemos que tenemos una base de datos de usuarios gestionada por un servicio web. Nuestro servicio utiliza un hipermedia personalizado basado en JSON, para el cual asignamos la aplicación mimetype / json + userdb (También puede haber una aplicación / xml + userdb y application / whatever + userdb - muchos tipos de medios pueden ser compatibles). El cliente y el servidor han sido programados para entender este formato, pero no saben nada el uno del otro. Como señala roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven :

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.

Una solicitud para el recurso base / podría devolver algo como esto:

Solicitud

GET / Accept: application/json+userdb

Respuesta

200 OK Content-Type: application/json+userdb { "version": "1.0", "links": [ { "href": "/user", "rel": "list", "method": "GET" }, { "href": "/user", "rel": "create", "method": "POST" } ] }

Sabemos por la descripción de nuestros medios que podemos encontrar información sobre recursos relacionados en las secciones llamadas "enlaces". Esto se llama controles de hipermedia . En este caso, podemos decir de una sección de este tipo que podemos encontrar una lista de usuarios haciendo otra solicitud para /user :

Solicitud

GET /user Accept: application/json+userdb

Respuesta

200 OK Content-Type: application/json+userdb { "users": [ { "id": 1, "name": "Emil", "country: "Sweden", "links": [ { "href": "/user/1", "rel": "self", "method": "GET" }, { "href": "/user/1", "rel": "edit", "method": "PUT" }, { "href": "/user/1", "rel": "delete", "method": "DELETE" } ] }, { "id": 2, "name": "Adam", "country: "Scotland", "links": [ { "href": "/user/2", "rel": "self", "method": "GET" }, { "href": "/user/2", "rel": "edit", "method": "PUT" }, { "href": "/user/2", "rel": "delete", "method": "DELETE" } ] } ], "links": [ { "href": "/user", "rel": "create", "method": "POST" } ] }

Podemos decir mucho de esta respuesta. Por ejemplo, ahora sabemos que podemos crear un nuevo usuario mediante POSTing to /user :

Solicitud

POST /user Accept: application/json+userdb Content-Type: application/json+userdb { "name": "Karl", "country": "Austria" }

Respuesta

201 Created Content-Type: application/json+userdb { "user": { "id": 3, "name": "Karl", "country": "Austria", "links": [ { "href": "/user/3", "rel": "self", "method": "GET" }, { "href": "/user/3", "rel": "edit", "method": "PUT" }, { "href": "/user/3", "rel": "delete", "method": "DELETE" } ] }, "links": { "href": "/user", "rel": "list", "method": "GET" } }

También sabemos que podemos cambiar los datos existentes:

Solicitud

PUT /user/1 Accept: application/json+userdb Content-Type: application/json+userdb { "name": "Emil", "country": "Bhutan" }

Respuesta

200 OK Content-Type: application/json+userdb { "user": { "id": 1, "name": "Emil", "country": "Bhutan", "links": [ { "href": "/user/1", "rel": "self", "method": "GET" }, { "href": "/user/1", "rel": "edit", "method": "PUT" }, { "href": "/user/1", "rel": "delete", "method": "DELETE" } ] }, "links": { "href": "/user", "rel": "list", "method": "GET" } }

Tenga en cuenta que estamos utilizando diferentes verbos HTTP (GET, PUT, POST, DELETE, etc.) para manipular estos recursos, y que el único conocimiento que presumimos de los clientes es nuestra definición de medios.

Otras lecturas:

(Esta respuesta ha sido objeto de una buena cantidad de críticas por no haber podido comprenderlo. En su mayor parte, ha sido una crítica justa. Lo que describí originalmente estaba más en línea con la forma en que se implementó normalmente REST hace unos años, cuando Primero escribí esto, en lugar de su verdadero significado. He revisado la respuesta para representar mejor el significado real.)

¿Qué es la prueba API ?

Las pruebas de API utilizan la programación para enviar llamadas a la API y obtener el rendimiento. La prueba considera el segmento bajo prueba como una caja negra. El objetivo de las pruebas API es confirmar la ejecución correcta y el tratamiento erróneo de la parte que precede a su coordinación en una aplicación.

API REST

RESTO: Transferencia de Estado Representacional.

  • Es una disposición de funciones en la que los evaluadores realizan solicitudes y reciben respuestas. En la API REST las interacciones se realizan a través del protocolo HTTP.
  • REST también permite la comunicación entre computadoras entre sí a través de una red.
  • Para enviar y recibir mensajes, implica el uso de métodos HTTP y no requiere una definición de mensaje estricta, a diferencia de los servicios web.
  • Los mensajes REST a menudo aceptan el formulario en forma de XML o de notación de objetos de JavaScript (JSON).

4 Métodos API de uso común: -

  1. GET: - Proporciona acceso de solo lectura a un recurso.
  2. POST: - Se utiliza para crear o actualizar un nuevo recurso.
  3. PUT: - Se utiliza para actualizar o reemplazar un recurso existente o crear un nuevo recurso.
  4. ELIMINAR: - Se usa para eliminar un recurso.

Pasos para probar la API manualmente: -

Para usar la API manualmente, podemos usar los complementos de la API de REST basados ​​en el navegador.

  1. Instalar el complemento POSTMAN (Chrome) / REST (Firefox)
  2. Ingrese la URL de la API
  3. Seleccione el método REST
  4. Seleccionar contenido-Encabezado
  5. Ingresar Solicitud JSON (POST)
  6. Haga clic en enviar
  7. Se devolverá la respuesta de salida

Pasos para automatizar la API REST

RESTO significa transferencia estatal representativa .

Se basa en un protocolo de comunicaciones sin estado, cliente-servidor, almacenable en caché, y en prácticamente todos los casos, se utiliza el protocolo HTTP.

REST se usa a menudo en aplicaciones móviles, sitios web de redes sociales, herramientas de mashup y procesos comerciales automatizados. El estilo REST enfatiza que las interacciones entre clientes y servicios se mejoran al tener un número limitado de operaciones (verbos). La flexibilidad se proporciona al asignar a los recursos (sustantivos) sus propios indicadores únicos de recursos universales (URI).

Introducción sobre el descanso

El punto de reposo es que si aceptamos usar un lenguaje común para las operaciones básicas (los verbos http), la infraestructura se puede configurar para comprenderlos y optimizarlos correctamente, por ejemplo, haciendo uso de encabezados de almacenamiento en caché para implementar el almacenamiento en caché. niveles

Con una operación GET reparadora correctamente implementada, no debería importar si la información proviene de la base de datos de su servidor, el memcache de su servidor, un CDN, la caché de un proxy, la caché de su navegador o el almacenamiento local de su navegador. Se puede utilizar la fuente actualizada, más rápida y fácilmente disponible.

Decir que Rest es solo un cambio sintáctico de usar solicitudes GET con un parámetro de acción a usar los verbos http disponibles hace que parezca que no tiene beneficios y es puramente cosmético. El punto es usar un lenguaje que pueda ser comprendido y optimizado por cada parte de la cadena. Si su operación GET tiene una acción con efectos secundarios, debe omitir todo el almacenamiento en caché HTTP o terminará con resultados inconsistentes.

Esta es una "discusión" asombrosamente larga y, sin embargo, bastante confusa por decir lo menos.

OMI:

1) No hay tal cosa como una programación tranquila, sin una gran articulación y mucha cerveza :)

2) Representational State Transfer (REST) ​​es un estilo arquitectónico especificado en la disertación de Roy Fielding . Tiene una serie de restricciones. Si su Servicio / Cliente los respeta, entonces es REST. Eso es todo.

Puede resumir (significativamente) las restricciones para:

  • comunicación sin estado
  • respete las especificaciones HTTP (si se usa HTTP)
  • Comunica claramente los formatos de contenido transmitidos.
  • Utilizar el hipermedia como motor de estado de aplicación.

Hay otro roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven que explica las cosas muy bien.

Muchas respuestas copian / pegan información válida, la mezclan y agregan cierta confusión. La gente habla aquí sobre niveles, sobre RESTFul URIs (¡no existe tal cosa!), Aplica los métodos HTTP GET, POST, PUT ... REST no es sobre eso o no solo sobre eso.

Por ejemplo, enlaces: es bueno tener una API bellamente atractiva, pero al final el cliente / servidor no se preocupa realmente de los enlaces que recibe / envía, es el contenido lo que importa.

Al final, cualquier cliente RESTful debería poder consumir a cualquier servicio RESTful siempre que se conozca el formato del contenido.

REST es un estilo de arquitectura de software de sistemas distribuidos (como WWW), se puede imaginar que se trata de reglas de aplicación web bien diseñadas: un grupo de páginas web de Internet (una máquina de estado virtual), en las que se encuentra el enlace al hacer clic en el enlace ), el resultado es la siguiente página web (lo que significa el siguiente estado de la aplicación).

REST describe el sistema de red que consta de tres partes:

  1. Elementos de datos (recurso, identificador de recurso, representación)
  2. conectores (cliente, servidor, caché, resolución, túnel)
  3. componentes (servidor de origen, puerta de enlace, proxy, agente de usuario)

RESTO cumple estrictamente las siguientes condiciones:

  1. El estado de la funcionalidad de la aplicación se divide en recursos
  2. Cada recurso utilizado como sintaxis de posicionamiento de hipervínculos (es decir, en el URI de WWW)
  3. Todos los recursos comparten una interfaz uniforme entre el cliente y el estado de transición de recursos, que incluye:
    1. Un conjunto limitado de operaciones bien definidas (es decir, en HTTP GET / POST / PUT / DELETE)
    2. Un conjunto limitado de tipos de contenido de formato de contenido, que pueden incluir código ejecutable (es decir, en la WWW Javascript)

Si tuviera que reducir la disertación original sobre REST a solo 3 oraciones cortas, creo que lo siguiente capta su esencia:

  1. Los recursos se solicitan a través de URLs.
  2. Los protocolos se limitan a lo que puede comunicar mediante el uso de URL.
  3. Los metadatos se pasan como pares nombre-valor (parámetros de cadena de consulta y datos de publicación).

Después de eso, es fácil caer en debates sobre adaptaciones, convenciones de codificación y mejores prácticas.

Curiosamente, no se mencionan las operaciones HTTP POST, GET, DELETE o PUT en la disertación. Esa debe ser la interpretación posterior de alguien de una "mejor práctica" para una "interfaz uniforme".

Cuando se trata de servicios web, parece que necesitamos alguna forma de distinguir las arquitecturas basadas en WSDL y SOAP que agregan una sobrecarga considerable y posiblemente una complejidad innecesaria a la interfaz. También requieren marcos adicionales y herramientas de desarrollo para implementar. No estoy seguro de si REST es el mejor término para distinguir entre las interfaces de sentido común y las interfaces excesivamente diseñadas como WSDL y SOAP. Pero necesitamos algo.

Un estilo arquitectónico llamado REST (Representational State Transfer) aboga por que las aplicaciones web deban usar HTTP como fue originalmente previsto . Las búsquedas deben utilizar solicitudes GET . GET deben usarse para la mutación, creación y eliminación, respectivamente .

Los proponentes de REST tienden a favorecer las URL, como

http://myserver.com/catalog/item/1729

pero la arquitectura REST no requiere estas "URL bonitas". Una petición GET con un parámetro.

http://myserver.com/catalog?item=1729

es tan RESTful.

Tenga en cuenta que las solicitudes GET nunca deben utilizarse para actualizar la información. Por ejemplo, una solicitud GET para agregar un artículo a un carrito

http://myserver.com/addToCart?cart=314159&item=1729

no sería apropiado Las solicitudes GET deben ser idempotent . Es decir, emitir una solicitud dos veces no debería ser diferente de emitirla una vez. Eso es lo que hace que las solicitudes sean cacheables. Una solicitud de "agregar al carrito" no es idempotente: emitirla dos veces agrega dos copias del artículo al carrito. Una solicitud POST es claramente apropiada en este contexto. Por lo tanto, incluso una aplicación web RESTful necesita su parte de las solicitudes POST.

Esto está tomado del excelente libro Core JavaServer faces book de David M. Geary.

Aquí está mi esquema básico de REST. Intenté demostrar el pensamiento detrás de cada uno de los componentes en una arquitectura REST para que entender el concepto sea más intuitivo. ¡Esperemos que esto ayude a desmitificar REST para algunas personas!

REST (Representational State Transfer) es una arquitectura de diseño que describe cómo se diseñan y se abordan los recursos en red (es decir, los nodos que comparten información). En general, una arquitectura REST hace que el cliente (la máquina solicitante) y el servidor (la máquina que responde) puedan solicitar leer, escribir y actualizar datos sin que el cliente tenga que saber cómo funciona el servidor y cómo puede pasar el servidor. Volver sin necesidad de saber nada sobre el cliente. Bien, genial ... pero ¿cómo hacemos esto en la práctica?

  • El requisito más obvio es que debe haber un lenguaje universal de algún tipo para que el servidor pueda decirle al cliente qué está tratando de hacer con la solicitud y para que el servidor responda.

  • Pero para encontrar un recurso determinado y luego decirle al cliente dónde vive ese recurso, debe haber una manera universal de señalar los recursos. Aquí es donde los identificadores universales de recursos (URI) entran; Son básicamente direcciones únicas para encontrar los recursos.

Pero la arquitectura REST no termina ahí! Si bien lo anterior satisface las necesidades básicas de lo que queremos, también queremos tener una arquitectura que admita un alto volumen de tráfico, ya que cualquier servidor dado generalmente maneja las respuestas de varios clientes. Por lo tanto, no queremos abrumar al servidor haciéndole recordar información sobre solicitudes anteriores.

  • Por lo tanto, imponemos la restricción de que cada par de solicitud-respuesta entre el cliente y el servidor es independiente, lo que significa que el servidor no tiene que recordar nada sobre las solicitudes anteriores (estados anteriores de la interacción cliente-servidor) para responder a una nueva solicitud. Esto significa que queremos que nuestras interacciones sean apátridas.

  • Para aliviar aún más la tensión en nuestro servidor de rehacer los cálculos que ya se han realizado recientemente para un cliente determinado, REST también permite el almacenamiento en caché. Básicamente, el almacenamiento en caché significa tomar una instantánea de la respuesta inicial proporcionada al cliente. Si el cliente vuelve a realizar la misma solicitud, el servidor puede proporcionar al cliente la instantánea en lugar de rehacer todos los cálculos necesarios para crear la respuesta inicial. Sin embargo, dado que es una instantánea, si la instantánea no ha caducado (el servidor establece un tiempo de caducidad por adelantado) y la respuesta se ha actualizado desde la memoria caché inicial (es decir, la solicitud daría una respuesta diferente a la respuesta en caché) , el cliente no verá las actualizaciones hasta que la memoria caché caduque (o la memoria caché se borre) y la respuesta se vuelva a procesar desde cero.

  • Lo último que encontrará a menudo aquí sobre las arquitecturas RESTful es que están en capas. En realidad, ya hemos estado discutiendo implícitamente este requisito en nuestra discusión de la interacción entre el cliente y el servidor. Básicamente, esto significa que cada capa en nuestro sistema interactúa solo con capas adyacentes. En nuestra discusión, la capa de cliente interactúa con nuestra capa de servidor (y viceversa), pero puede haber otras capas de servidor que ayuden al servidor primario a procesar una solicitud con la que el cliente no se comunica directamente. Más bien, el servidor pasa la solicitud según sea necesario.

Ahora, si todo esto suena familiar, entonces genial. El Protocolo de transferencia de hipertexto (HTTP), que define el protocolo de comunicación a través de la World Wide Web, es una implementación de la noción abstracta de arquitectura REST (o una instancia de la clase REST si eres un fanático de la POO como yo). En esta implementación de REST, el cliente y el servidor interactúan a través de GET, POST, PUT, DELETE, etc., que forman parte del lenguaje universal y los recursos se pueden señalar mediante URL.

Creo que el punto de descanso es la separación de la condición de estado en una capa superior mientras se hace uso de Internet (protocolo) como una capa de transporte sin estado . La mayoría de los otros enfoques mezclan las cosas.

Ha sido el mejor enfoque práctico para manejar los cambios fundamentales de la programación en la era de Internet. En cuanto a los cambios fundamentales, Erik Meijer tiene una discusión en el programa aquí: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Lo resume como los cinco efectos y presenta una solución mediante el diseño de la solución en un lenguaje de programación. La solución, también podría lograrse a nivel de plataforma o sistema, independientemente del idioma. El descanso puede verse como una de las soluciones que ha tenido mucho éxito en la práctica actual.

Con un estilo relajado, obtiene y manipula el estado de la aplicación a través de un Internet no confiable. Si falla la operación actual para obtener el estado correcto y actual, necesita el principio de validación cero para ayudar a la aplicación a continuar. Si no logra manipular el estado, usualmente usa múltiples etapas de confirmación para mantener las cosas correctas. En este sentido, el descanso no es en sí mismo una solución completa, necesita las funciones en otra parte de la pila de aplicaciones web para que funcione.

Teniendo en cuenta este punto de vista, el estilo de descanso no está realmente vinculado a Internet o a la aplicación web. Es una solución fundamental para muchas de las situaciones de programación. Tampoco es simple, simplemente hace que la interfaz sea realmente simple y hace frente a otras tecnologías sorprendentemente bien.

Sólo mi 2c.

Edición: Dos aspectos más importantes:

Esto se menciona mucho menos en todas partes, pero el Modelo de madurez de Richardson es uno de los mejores métodos para juzgar realmente cuán apacible es su API. Más sobre esto aquí:

Modelo de madurez de Richardson

No existe tal noción como "programación RESTful" per se. Se llamaría mejor paradigma RESTful o incluso mejor arquitectura RESTful. No es un lenguaje de programación. Es un paradigma.

De Wikipedia :

En computación, la transferencia de estado representacional (REST) ​​es un estilo arquitectónico utilizado para el desarrollo web.

REST === La analogía de HTTP no es correcta hasta que no se enfatice en el hecho de que "DEBE" ser manejado por HATEOAS .

Roy mismo lo aclaró roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven .

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, los cuales 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 define 6 restricciones arquitectónicas que hacen que cualquier servicio web sea una verdadera API RESTful .

  1. Interfaz uniforme
  2. Servidor de cliente
  3. Apátrida
  4. Cacheable
  5. Sistema de capas
  6. Código bajo demanda (opcional)

https://restfulapi.net/rest-architectural-constraints/

REST es un patrón arquitectónico y estilo de escritura de aplicaciones distribuidas. No es un estilo de programación en sentido estricto.

Decir que usa el estilo REST es similar a decir que construyó una casa en un estilo particular: por ejemplo, Tudor o Victorian. Tanto REST como estilo de software como Tudor o Victorian como estilo de hogar pueden definirse por las cualidades y restricciones que los conforman. Por ejemplo, REST debe tener una separación de Client Server donde los mensajes se autodescriben. Las casas de estilo Tudor tienen gabletes superpuestos y techos que se inclinan abruptamente con frontones frontales. Puede leer la disertación de Roy para aprender más sobre las limitaciones y cualidades que conforman REST.

A diferencia de los estilos caseros, REST ha tenido dificultades para ser aplicado de manera consistente y práctica. Esto puede haber sido intencional. Dejando su implementación actual hasta el diseñador. Por lo tanto, es libre de hacer lo que quiera siempre que cumpla con las restricciones establecidas en la disertación que está creando Sistemas REST.

Prima:

Toda la web se basa en REST (o REST se basa en la web). Por lo tanto, como desarrollador web es posible que desee saberlo, aunque no es necesario escribir buenas aplicaciones web.

Vieja pregunta, nueva forma de responder. Hay muchos conceptos erróneos sobre este concepto. Siempre trato de recordar:

  1. Las URL estructuradas y los Métodos / Verbos de HTTP no son la definición de programación tranquila.
  2. JSON no es una programación tranquila
  3. La programación REST no es para APIs

Defino la programación tranquila como

Una aplicación es tranquila si proporciona recursos (como la combinación de datos + controles de transiciones de estado) en un tipo de medio que el cliente entiende

Para ser un programador tranquilo, debe estar intentando crear aplicaciones que permitan a los actores hacer cosas. No solo exponiendo la base de datos.

Los controles de transición de estado solo tienen sentido si el cliente y el servidor acuerdan una representación de tipo de medio del recurso. De lo contrario, no hay manera de saber qué es un control y qué no, y cómo ejecutar un control. IE si los navegadores no conocían las etiquetas en html, no habría nada que enviar al estado de transición en su navegador.

No busco la auto-promoción, pero amplío estas ideas con gran profundidad en mi charla http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .