¿Qué es exactamente la programación RESTful?

¿Qué es exactamente la programación RESTful?

Un estilo arquitectónico llamado REST (Representational State Transfer) aboga por que las aplicaciones web deben usar HTTP como se concibió originalmente . Las búsquedas deben usar GETsolicitudes. PUT, POSTy las DELETEsolicitudes deben usarse para 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 solicitud GET con un parámetro

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

es tan RESTful.

Tenga en cuenta que las solicitudes GET nunca deben usarse 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 idempotentes . Es decir, emitir una solicitud dos veces no debería ser diferente de emitirla una vez. Eso es lo que hace que las solicitudes se puedan almacenar en caché. 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 solicitudes POST.

Esto está tomado del excelente libro Core JavaServer enfrenta el libro de David M. Geary.

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 formas complejas sin que el cliente sepa de antemano nada sobre el servidor y los recursos que alberga. La restricción clave es que el servidor y el cliente deben acordar 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 necesita 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 obligatorios. 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 completamente proporcionadas por el servidor. (Este principio se llama HATEOAS : Hypermedia 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 a verbos y recursos. Los dos verbos en el uso principal son GETy POST, que creo que todos reconocerán. Sin embargo, el estándar HTTP define varios otros como PUTy DELETE. Estos verbos luego 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 administrada por un servicio web. Nuestro servicio utiliza un hipermedia personalizado basado en JSON, para el cual asignamos el tipo MIME application/json+userdb(también puede haber un application/xml+userdby application/whatever+userdb, muchos tipos de medios pueden ser compatibles). El cliente y el servidor han sido programados para comprender este formato, pero no saben nada el uno del otro. Como Roy Fielding señala:

Una API REST debería 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 para definir nombres de relaciones extendidas y / o marcado habilitado para 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"
        }
    ]
}

Por la descripción de nuestros medios, sabemos que podemos encontrar información sobre recursos relacionados en secciones llamadas "enlaces". Esto se llama controles hipermedia . En este caso, podemos deducir de esa sección 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 POSTal /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, DELETEetc.) para manipular estos recursos, y que el único conocimiento se presume por parte del cliente es nuestra definición de los medios.

Otras lecturas:

• Las muchas mejores respuestas en esta misma página.
• Cómo le expliqué RESTO a mi esposa .
• Cómo le expliqué RESTO a mi esposa .
• Pensamientos de Martin Fowler
• La API de PayPal tiene controles hipermedia

(Esta respuesta ha sido objeto de una buena cantidad de críticas por perder el punto. 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 REST se implementó generalmente hace unos años cuando yo primero escribí esto, en lugar de su verdadero significado. Revisé la respuesta para representar mejor el significado real).

La programación RESTful se trata de:

• recursos que se identifican mediante un identificador persistente: los URI son la elección ubicua del identificador en estos días
• recursos que están siendo manipulados usando un conjunto común de verbos: HTTP métodos son el caso comúnmente visto - el venerable Create, Retrieve, Update, Deletese convierte 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 los encabezados de aceptación para controlar si desea XML, HTTP o incluso un objeto Java que represente el recurso
• mantener el estado en el objeto y representar el estado en la representación
• representando las relaciones entre recursos en la representación del recurso: los enlaces entre objetos están incrustados directamente en la representación
• las representaciones de recursos describen cómo se puede usar la representación y en qué circunstancias se debe descartar / volver a buscar de manera coherente: 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 RESTful parecen centrarse en HTTP y su uso desde un navegador y demás. Entiendo que R. Fielding acuñó el término cuando describió la arquitectura y las decisiones que condujeron a HTTP. Su tesis trata más sobre la arquitectura y la capacidad de caché de los recursos que sobre HTTP.

Si está realmente interesado en qué es una arquitectura RESTful y por qué funciona, lea su tesis varias veces y lea todo, ¡ no solo el Capítulo 5! A continuación, analice por qué funciona DNS . Lea sobre la organización jerárquica de DNS y cómo funcionan las referencias. Luego lea y considere 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. Finalmente, solo hará clic. La revelación final para mí fue cuando vi la similitud entre DNS y HTTP. Después de esto, entender por qué las interfaces de paso de mensajes y SOA son escalables comienza a hacer clic.

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

Esto es lo que podría parecer.

Cree 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 ( lnamey agepermanecerá sin cambios):

PATCH /user/123
fname=Johnny

Para actualizar el registro (y, en consecuencia lname, y ageserá nulo):

PUT /user/123
fname=Johnny

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

Las lecturas obligatorias son Transferencia de estado representacional (REST) y las API REST deben ser impulsadas por hipertexto

Consulte el artículo de Martin Fowlers, el Modelo de madurez de Richardson (RMM) para obtener una explicación sobre qué es un servicio RESTful.

Para estar RESTANTE, un Servicio necesita cumplir con el Hypermedia como el Motor del Estado de la Aplicación. (HATEOAS) , es decir, necesita alcanzar el nivel 3 en el RMM, lea el artículo para obtener detalles o las diapositivas de la charla de qcon .

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 cliente.

...

Un cliente de una aplicación RESTful solo necesita conocer una única URL fija para acceder a ella. Todas las acciones futuras deben poder descubrirse dinámicamente desde enlaces 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 frameworks web.

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

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

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

¿Qué es REST?

REST significa Transferencia de Estado representativa. (A veces se deletrea "ReST"). Se basa en un protocolo de comunicaciones sin caché, cliente-servidor y almacenable en caché, y en prácticamente 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 use 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 usan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, realizar consultas) y eliminar datos. Por lo tanto, REST usa HTTP para las cuatro operaciones CRUD (Crear / Leer / Actualizar / Eliminar).

REST es una alternativa ligera a mecanismos como RPC (Llamadas de procedimiento remoto) 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 hay nada que pueda hacer en los servicios web que no se pueda hacer con una arquitectura RESTful. REST no es un "estándar". Nunca habrá una recomendación del W3C para REST, por ejemplo. Y si bien existen marcos de programación REST, trabajar con REST es tan simple que a menudo puede "implementar el suyo" con funciones de biblioteca estándar en lenguajes como Perl, Java o C #.

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

http://rest.elkstein.org/

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

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

Por ejemplo, en su lugar, un conjunto de URL que podrían 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

Utiliza los "verbos" HTTP y tiene ..

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

Es la programación donde la arquitectura de su sistema se ajusta al estilo REST presentado por Roy Fielding en su tesis . Dado que este es el estilo arquitectónico que describe la web (más o menos), mucha gente está interesada en ella.

Respuesta adicional: 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.

Diría que la programación RESTful se trataría de crear sistemas (API) que sigan el estilo arquitectónico REST.

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

Aprenda REST: un tutorial

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 use 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 usan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, realizar consultas) y eliminar datos. Por lo tanto, REST usa HTTP para las cuatro operaciones CRUD (Crear / Leer / Actualizar / Eliminar).

¡No creo que debas sentirte estúpido por no haber escuchado sobre REST fuera de Stack Overflow ..., estaría en la misma situación !; Las respuestas a esta otra pregunta SO sobre por qué REST se está haciendo grande ahora podrían aliviar algunos sentimientos.

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 terminología.

Hay un buen ejemplo aquí:

Explicando REST e hipertexto: Spam-E, el robot de limpieza de spam

Y aún mejor, hay una explicación clara con ejemplos simples aquí (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 dice que REST está impulsado por el hipertexto. Sin embargo, no estoy 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 INESTABLE solo porque el cliente lo sabe "fuera de banda".

Ese documento de xfront explica la diferencia entre REST y SOAP, y esto también es realmente útil. Cuando Fielding dice: " Eso es RPC. Grita RPC ", está claro que RPC no es RESTful, por lo que es útil ver las razones exactas de esto. (SOAP es un tipo de RPC).

¿Qué es REST?

REST en palabras oficiales, REST es un estilo arquitectónico basado en ciertos principios que utiliza los fundamentos actuales de la "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 arquitectónico 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: Use interfaces simples y uniformes
• Principio 4: la comunicación se realiza por representación
• Principio 5: Ser apátrida

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

Roy Fielding, quien acuñó el término, dice que las API REST deben estar impulsadas por el hipertexto . 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 RESTful. Un buen uso de HTTP, tal vez, tal vez no. Pero no descansa. Tiene que venir del hipertexto.

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

El término RESTful se creó porque ppl agotó la palabra REST llamando a su aplicación no REST como REST. Después de eso, el término RESTful también se agotó. Hoy en día estamos hablando de API web y API de hipermedia , porque la mayoría de las llamadas aplicaciones REST no cumplían 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, tomas 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 utilizar el servidor de un almacenamiento de sesión lateral y debe autenticar cada solicitud. Sus clientes posiblemente envíen encabezados de autenticación básicos a través de una conexión cifrada. (En aplicaciones grandes es difícil mantener muchas sesiones).

3. uso de caché si puedes

   Por lo tanto, no tiene que atender las mismas solicitudes una y otra vez.

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

   El servidor no mantiene el contrato entre el cliente y el servidor. En otras palabras, el cliente debe estar desacoplado de la implementación del servicio. Puede alcanzar este estado mediante el uso de 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 vocabulario RDF, microformatos, etc.) para Describa la semántica de diferentes partes del cuerpo del mensaje. Para desacoplar la estructura IRI del cliente, debe enviar hipervínculos a los clientes en formatos hipermedia como (HTML, JSON-LD, HAL, etc.). Por lo tanto, un cliente puede usar los metadatos (posiblemente relaciones de enlace, vocabulario RDF) asignados a los hipervínculos para navegar en la máquina de estado 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, encuentra uno descrito con 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 POST https://example.com/api/v1/ordermensaje con el cuerpo adecuado. Después de eso, el servicio procesa el mensaje y responde con el resultado que tiene el encabezado de estado HTTP adecuado, por ejemplo, 201 - createdcon éxito. Para anotar mensajes con metadatos detallados, la solución estándar para usar un formato RDF, por ejemplo JSON-LD con un vocabulario REST, por ejemplo Hydra vocablos específicos de y dominios comoschema.org o cualquier otrovocabulario de datos vinculadosy tal vez un vocabulario específico de aplicación personalizada si es necesario. Ahora, esto no es fácil, es por eso que la mayoría de las personas usan HAL y otros formatos simples que generalmente proporcionan solo un vocabulario REST, pero no admiten 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 componentes que se encuentran en la siguiente capa a continuación. Para que pueda agregar nuevas capas y componentes sin esfuerzo.

   Por ejemplo, hay una capa de cliente que contiene los clientes y debajo 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, etc. El código del cliente y el código del servicio no cambiarán.

6. código bajo demanda 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 se conectará a la solución del cargador de complementos .

Las restricciones REST dan como resultado un sistema altamente escalable en el que los clientes están desacoplados de las implementaciones de los servicios. Por lo tanto, los clientes pueden ser reutilizables, en general, al igual que los navegadores en la web. Los clientes y los servicios comparten los mismos estándares y vocabulario, por lo que pueden entenderse entre sí a pesar 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 mutuamente sus tareas, al igual que los humanos. Si agregamos patrones de aprendizaje a dichos clientes, el resultado será una o más IA utilizando la web de máquinas en lugar de un solo parque de servidores. Entonces, al final, el sueño de Berners Lee: la web semántica y la inteligencia artificial serán realidad. Entonces, en 2030, terminamos en el Skynet. Hasta entonces ... ;-)

La programación API RESTful (transferencia de estado representativa) es escribir aplicaciones web en cualquier lenguaje de programación siguiendo 5 principios básicos de estilo arquitectónico de software :

1. Recurso (datos, información).
2. Identificador global único (todos los recursos son identificados de forma única por URI ).
3. Interfaz uniforme : use una interfaz simple y estándar (HTTP).
4. Representación: toda la comunicación se realiza por representación (por ejemplo, XML / JSON )
5. Sin estado (cada solicitud se realiza de forma completamente aislada, es más fácil almacenar en caché y equilibrar la carga),

En otras palabras, está escribiendo aplicaciones simples de red punto a punto sobre HTTP que utiliza verbos como GET, POST, PUT o DELETE mediante la implementación de una arquitectura RESTful que propone la estandarización de la interfaz que expone cada "recurso". No es nada que utilice 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 RESTful se ajusta al diseño de la arquitectura web y, si se implementa adecuadamente, le permite aprovechar al máximo la infraestructura web escalable.

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

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

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 su implementación. No estoy seguro de si REST es el mejor término para distinguir entre interfaces de sentido común e interfaces excesivamente diseñadas como WSDL y SOAP. Pero necesitamos algo.

REST es un patrón arquitectónico y un 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 Victoriano. Tanto REST como un estilo de software y Tudor o victoriano como un estilo hogareño se pueden definir por las cualidades y limitaciones que los componen. Por ejemplo, REST debe tener una separación del Servidor del Cliente donde los mensajes se autodescriban. Las casas de estilo Tudor tienen frontones y techos superpuestos que están abruptamente inclinados con frontones orientados hacia el frente. Puede leer la tesis de Roy para obtener más información sobre las limitaciones y cualidades que conforman REST.

REST, a diferencia de los estilos de hogar, ha tenido dificultades para aplicarse de manera consistente y práctica. Esto puede haber sido intencional. Dejando su implementación real al diseñador. Por lo tanto, es libre de hacer lo que quiera, siempre y cuando 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 basó en la web). Por lo tanto, como desarrollador web, es posible que desee saberlo, aunque no es necesario escribir buenas aplicaciones web.

Aquí está mi resumen básico de REST. Traté de demostrar el pensamiento detrás de cada uno de los componentes en una arquitectura RESTful para que la comprensión del concepto sea más intuitiva. ¡Ojalá 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 RESTful 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 el servidor puede pasar de vuelta 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 existir un lenguaje universal de algún tipo para que el servidor pueda decirle al cliente qué está tratando de hacer con la solicitud y que el servidor responda.

• Pero para encontrar cualquier recurso dado y luego decirle al cliente dónde vive ese recurso, debe haber una forma universal de señalar los recursos. Aquí es donde entran los identificadores universales de recursos (URI); 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 tráfico de gran volumen ya que cualquier servidor determinado generalmente maneja las respuestas de varios clientes. Por lo tanto, no queremos abrumar al servidor al hacer que recuerde 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 solicitudes anteriores (estados anteriores de la interacción cliente-servidor) para responder a un nuevo 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 hacer la misma solicitud, el servidor puede proporcionarle 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 expirado (el servidor establece un tiempo de vencimiento por adelantado) y la respuesta se ha actualizado desde la caché inicial (es decir, la solicitud daría una respuesta diferente a la respuesta en caché) , el cliente no verá las actualizaciones hasta que caduque el caché (o se borre el caché) y la respuesta se vuelva a presentar desde cero.

• Lo último que encontrarás a menudo sobre las arquitecturas RESTful es que están en capas. De hecho, ya hemos estado discutiendo implícitamente este requisito en nuestra discusión sobre 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. Entonces, en nuestra discusión, la capa del cliente interactúa con nuestra capa del servidor (y viceversa), pero puede haber otras capas del servidor que ayudan al servidor primario a procesar una solicitud con la que el cliente no se comunica directamente. Por el contrario, 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 RESTful (o una instancia de la clase REST si eres un fanático de OOP 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 son parte del lenguaje universal y se puede apuntar a los recursos mediante URL.

Creo que el punto de descanso es la separación de la capacidad 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. Con respecto 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 diseñando 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 podría verse como una de las soluciones que ha tenido mucho éxito en la práctica actual.

Con un estilo tranquilo, obtienes y manipulas el estado de la aplicación en un Internet poco confiable. Si falla la operación actual para obtener el estado correcto y actual, necesita el principal de validación cero para ayudar a que la aplicación continúe. Si no logra manipular el estado, generalmente 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 soportar su funcionamiento.

Dado 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.

Solo mi 2c.

Editar: Dos aspectos más importantes:

• La apatridia es engañosa. Se trata de la API tranquila, no de la aplicación o el sistema. El sistema debe tener estado. El diseño reparador consiste en diseñar un sistema con estado basado en una API sin estado. Algunas citas de otro control de calidad :

  • REST, opera en representaciones de recursos, cada una identificada por una URL. Por lo general, no son objetos de datos, sino abstracciones de objetos complejos .
  • REST significa "transferencia de estado representacional", lo que significa que se trata de comunicar y modificar el estado de algún recurso en un sistema.

• Idempotencia : una parte a menudo pasada por alto de REST es la idempotencia de la mayoría de los verbos. Eso lleva a sistemas robustos y menos interdependencia de interpretaciones exactas de la semántica .

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

OMI:

1) No existe una programación tranquila, sin un gran porro y mucha cerveza :)

2) La transferencia de estado representacional (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 RESTful. Eso es todo.

Puede resumir (significativamente) las restricciones para:

• comunicación sin estado
• respetar las especificaciones HTTP (si se usa HTTP)
• comunica claramente los formatos de contenido transmitidos
• utilizar hipermedia como motor del estado de la aplicación

Hay otra publicación muy buena que explica muy bien las cosas.

Muchas respuestas copian / pegan información válida mezclándola y agregando algo de confusión. Aquí se habla de niveles, de URI RESTFul (¡no existe tal cosa!), Se aplican métodos HTTP GET, POST, PUT ... REST no se trata de eso o no solo de eso.

Por ejemplo, enlaces: es bueno tener una API que se vea hermosa, pero al final al cliente / servidor realmente no le importan los enlaces que obtienes / envías, es el contenido lo que importa.

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

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 Http no son la definición de programación tranquila.
2. JSON no es una programación tranquila
3. La programación RESTful no es para API

Defino programación tranquila como

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

Para ser un programador tranquilo, debe intentar 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 forma de saber qué es un control y qué no lo es, y cómo ejecutar un control. IE si los navegadores no sabían<form> etiquetas en html, entonces no habría nada que enviar al estado de transición en su navegador.

No estoy buscando auto promocionarme, pero amplío estas ideas con gran profundidad en mi charla http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

Un extracto de mi charla es sobre el modelo de madurez de richardson, a menudo referido, no creo en los niveles, o eres RESTful (nivel 3) o no lo eres, pero lo que me gusta mencionar es qué es cada nivel hace por ti en tu camino a RESTful

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. Caché
5. Sistema de capas
6. Código bajo demanda (opcional)

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

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

Roy mismo lo aclaró aquí .

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).

[El fracaso aquí implica que la información fuera de banda impulsa la interacción en lugar del hipertexto].

REST es un estilo arquitectónico que se basa 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 HTTP (GET, PUT, PATCH, DELETE, etc.).

En una arquitectura basada en REST, 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 HTTP. Los recursos se identifican mediante ID globales (que generalmente son 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 a través del protocolo HTTP (negociación de contenido).

Métodos HTTP:

Los métodos PUT, GET, POST y DELETE son típicamente utilizados 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 (idempotente).
• PUT crea un nuevo recurso. También debe ser idempotente.
• ELIMINAR elimina los recursos. Las operaciones son idempotentes. Pueden repetirse sin conducir a resultados diferentes.
• POST actualiza un recurso existente o crea un nuevo recurso.

REST significa transferencia de estado 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 asignando a los recursos (sustantivos) sus propios indicadores únicos de recursos universales (URI).

Introducción sobre el descanso

Hablar es más que simplemente intercambiar información . En realidad, un protocolo está 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 posibles acciones. Hablar, por otro lado, permite que una de las partes pregunte qué acciones adicionales 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 una arquitectura RESTful . La tesis de Fielding especifica la arquitectura que habría que seguir si se quisiera permitir que las máquinas hablen entre sí en lugar de simplemente para comunicarse .

No existe la noción de "programación RESTful" per se. Sería mejor llamado paradigma RESTful o incluso mejor arquitectura RESTful. No es un lenguaje de programación. Es un paradigma.

De Wikipedia :

En informática, la transferencia de estado de representación (REST) ​​es un estilo arquitectónico utilizado para el desarrollo web.

El punto de descanso es que si aceptamos usar un lenguaje común para operaciones básicas (los verbos http), la infraestructura se puede configurar para comprenderlos y optimizarlos adecuadamente, por ejemplo, haciendo uso de encabezados de 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, la memoria caché 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 en ayunas, más 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 entendido 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.

¿Qué son las pruebas de API ?

Las pruebas de API utilizan 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 de errores de la parte que precede a su coordinación en una aplicación.

API REST

RESTO: Transferencia representativa del estado.

• Es una disposición de funciones en la que los evaluadores realizan solicitudes y reciben respuestas. En REST API 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 estricta del mensaje, a diferencia de los servicios web.
• Los mensajes REST a menudo aceptan el formulario, ya sea en forma de XML o JavaScript Object Notation (JSON).

4 métodos API comúnmente utilizados: -

1. OBTENER: - 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. BORRAR: - Se utiliza para eliminar un recurso.

Pasos para probar la API manualmente: -

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

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

Pasos para automatizar la API REST

Esto es muy poco mencionado en todas partes, pero el Modelo de madurez de Richardson es uno de los mejores métodos para juzgar qué tan relajante es la API de uno. Más sobre esto aquí:

Modelo de madurez de Richardson

Diría que un elemento importante para comprender REST reside en los puntos finales o las asignaciones, como /customers/{id}/balance.

Puede imaginar un punto final como la tubería de conexión desde el sitio web (front-end) a su base de datos / servidor (back-end). Utilizándolos, el front-end puede realizar operaciones de back-end definidas en los métodos correspondientes de cualquier mapeo REST en su aplicación.