¿Qué es exactamente la programación RESTful?

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 nada de antemano sobre el servidor y los recursos que aloja. La restricción clave es que el servidor y el cliente deben estar de acuerdo en el medioutilizado, 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 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 proporcionadas 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 convencional 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 a las instrucciones proporcionadas por el servidor.

Por ejemplo, imaginemos que tenemos una base de datos de usuarios que es administrada por un servicio web. Nuestro servicio utiliza un hipermedia personalizado basado en JSON, para el que asignamos el tipo mime application/json+userdb (También puede haber una application/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 sabemos nada el uno del otro. Como Roy Fielding, señala:

Una API REST debería gastar casi todo su esfuerzo descriptivo en definición de los tipos de medios utilizados para representar recursos e impulsar estado de la aplicación, o en la definición de nombres de relaciones extendidas y / o marcado habilitado para hipertexto para 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 Hypermedia controls . En este caso, podemos decir de tal 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 publicando en /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"
    }
}

Observe que estamos usando diferentes verbos HTTP (GET, PUT, POST, DELETE, etc.) para manipular estos recursos, y que el único conocimiento que suponemos de parte de los clientes es nuestra definición de medios.

Lectura adicional:

• Las muchas respuestas mucho mejores en esta misma página.
• Cómo expliqué el DESCANSO a mi esposa .
• Cómo expliqué el DESCANSO a mi esposa.
• Martin Fowler pensamientos
• 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, esa 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 escribí esto por primera vez, en lugar de su verdadero significado. He revisado la respuesta para representar mejor el significado real.)

La programación RESTful se trata de:

• recursos identificados por un identificador persistente: los URI son la opción ubicua de identificador en estos días
• recursos siendo manipulados usando un conjunto común de verbos: los métodos HTTP son el caso comúnmente visto - el venerable Create, Retrieve, Update, Delete se 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 encabezados Accept 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
• representar las relaciones entre recursos en la representación del recurso: los enlaces entre objetos se incrustan directamente en la representación
• las representaciones de recursos describen cómo la representación puede ser utilizada y bajo qué circunstancias debe ser descartada/refetched de una manera consistente: uso de HTTP Cache-Control headers

El último es probablemente el más importante en términos de consecuencias y efectividad general del DESCANSO. En general, la mayoría de las discusiones RESTful 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 thesis trata más sobre la arquitectura y la capacidad de caché de los recursos que sobre HTTP.

Si estás realmente interesado en lo que es una arquitectura tranquila y por qué funciona, lee su tesis unas cuantas veces y lee todo el asunto ¡no solo el Capítulo 5! A continuación, analice por qué funciona DNS. Lea sobre la organización jerárquica del DNS y cómo funcionan las referencias. A continuación, lea y considere cómo funciona el almacenamiento en caché 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 que lo hace. Eventualmente, simplemente hará clic. La revelación final para mí fue cuando vi la similitud entre DNS y HTTP. Después de esto, comienza a hacer clic para comprender por qué las interfaces SOA y de Paso de mensajes son escalables.

Creo que el truco más importante para comprender la importancia arquitectónica y las implicaciones de rendimiento de un descanso y Compartido Nada las arquitecturas es evitar quedarse atascado en los detalles de la tecnología y la 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.

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á sin cambios):

PATCH /user/123
fname=Johnny

Para actualizar el registro (y consecuentemente lname y age será NULO):

PUT /user/123
fname=Johnny

Un gran libro sobre el DESCANSO es El DESCANSO en la práctica.

Las lecturas deben ser Representational State Transfer (REST) y Las API REST deben estar basadas en hipertexto

Vea el artículo de Martin Fowlers the Richardson Maturity Model (RMM) para una explicación de lo que es un servicio RESTful.

Para ser RESTful un Servicio necesita cumplir con el Hipermedia 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 más detalles o las diapositivas de la conversación de qcon.

La restricción HATEOAS es un acrónimo para Hypermedia como el Motor de Estado de la Aplicación. Este principio es el diferenciador clave entre un DESCANSO y la mayoría de las otras formas de servidor cliente sistema.

...

Un cliente de una aplicación RESTful necesita solo conoce una única URL fija para acceder se. Todas las acciones futuras deben ser detectable dinámicamente desde enlaces hipermedia incluidos en el representaciones de los recursos que se devuelven desde esa URL. Los tipos de medios estandarizados también son se espera que sea entendido por cualquier cliente que podría usar una API RESTful. (De Wikipedia, la enciclopedia libre)

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

Approaching pure REST: Learning to love HATEOAS es una buena colección de enlaces.

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

REST and versioning analiza la Extensibilidad, el Control de versiones, la Capacidad de evolución, etc. mediante modificabilidad

¿Qué es el DESCANSO?

REST significa Transferencia del Estado representativo. (Es a veces deletreado "descanso".) Se basa en un sin estado, cliente-servidor, cacheable protocolo de comunicaciones protocol y en prácticamente todos los casos, el HTTP se utiliza el protocolo.

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 conectar entre máquinas, HTTP simple se utiliza para hacer llamadas entre máquinas.

De muchas maneras, la propia World Wide Web, basada en HTTP, se puede ver como una arquitectura basada en REST. Las aplicaciones RESTful usan solicitudes HTTP para publicar datos (crear y/o actualizar), leer datos (p. ej., realizar consultas), y eliminar datos. Por lo tanto, REST utiliza HTTP para los cuatro CRUD (Crear/Leer/Actualizar/Eliminar) operaciones.

REST es una alternativa ligera a mecanismos como RPC (Remote Llamadas de Procedimiento) y Servicios Web (SOAP, WSDL, et al.). Más tarde, lo haremos mira cuánto más simple es el DESCANSO.

A pesar de ser simple, REST tiene todas las funciones; hay básicamente nada que pueda hacer en Servicios Web que no se pueda hacer con un RESTful arquitectura. El DESCANSO no es un"estándar". Nunca habrá un W3C recomendación para el DESCANSO, por ejemplo. Y mientras hay DESCANSO marcos de programación, trabajar con REST es tan simple que puede a menudo "roll your own" con funciones de biblioteca estándar en idiomas 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 utiliza varios métodos HTTP (principalmente GET/PUT/DELETE) para manipular datos.

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

Por ejemplo, en su lugar, un conjunto de URLs que podrían parecerse a algunas de las 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

Utilizas los "verbos" HTTP y has..

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

Es la programación donde la arquitectura de su sistema se ajusta al estilo REST establecido 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.

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

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

Aprender RESTO: UN Tutorial

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

• De muchas maneras, la propia World Wide Web, basada en HTTP, puede ser vista como una arquitectura basada en REST.

Las aplicaciones RESTful utilizan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, realizar consultas) y eliminar datos. Por lo tanto, EL DESCANSO utiliza HTTP para las cuatro operaciones CRUD (Create/Read/Update/Delete).

I no creas que debes sentirte estúpido por no escuchar sobre el DESCANSO fuera del desbordamiento de la pila..., Yo estaría en la misma situación!; respuestas a esta otra pregunta sobre Por qué el DESCANSO se está haciendo grande ahora podría aliviar algunos sentimientos.

Me disculpo 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.

Aquí hay un ejemplo bastante bueno:

Explicando REST e Hipertexto: Spam-E el Robot de Limpieza de Spam

Y aún mejor, hay una explicación limpia con ejemplos simples aquí (el powerpoint es más completo, pero puede obtener la mayor parte en el 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á impulsado por hipertexto. Sin embargo, no estoy seguro de que tenga razón, porque /user/123 es un URI que apunta a un recurso, y no está claro para mí que sea intranquilo 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, " 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 el DESCANSO?

REST en palabras oficiales, REST es un estilo arquitectónico construido sobre ciertos principios utilizando 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), normalmente enlaces en la Web.
• Principio 2: Todo Recurso se identifica mediante un Identificador único (URI)
• Principio 3: Utilizar Interfaces simples y Uniformes
• Principio 4: La Comunicación se hace 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 basadas en hipertexto . En particular, "Una API REST no debe definir nombres o jerarquías de recursos fijos".

Así que si tu ruta "/user/123" está codificada en el cliente, no es realmente RESTful. Un buen uso de HTTP, tal vez, tal vez no. Pero no tranquilo. Tiene que venir de hipertexto.

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

El término RESTful fue creado porque ppl agotó la palabra REST llamando a su aplicación no REST como REST. Después de eso, el término Descanso también se agotó. Hoy en día estamos hablando de API web y API Hipermedia, porque la mayoría de las llamadas aplicaciones REST no cumplían con la parte de HATEOAS de la restricción de interfaz uniforme.

Las restricciones REST son las siguientes:

1. Arquitectura cliente-servidor

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

2. Comunicación sin estado

   Así que el servidor no mantiene los estados de los clientes. Esto significa que no puede usar el almacenamiento de sesiones del lado servidor y tienes que autenticar cada solicitud. Es posible que sus clientes envíen encabezados de autenticación básicos a través de una conexión cifrada. (Por grandes aplicaciones es difícil mantener muchas sesiones.)

3. Uso de caché si puede

   Para que no tenga que servir 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 describir 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 hypermedia formatos como (HTML, JSON-LD, HAL, etc.). Por lo tanto, un cliente puede usar los metadatos (posiblemente relaciones de enlace, 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 quiere enviar un pedido a una tienda web, entonces tiene que comprobar los hipervínculos en las respuestas enviadas por la tienda web. Comprobando los enlaces se encuentra uno descrito con el http://schema.org/OrderAction . El cliente conoce la schema.org vocab, 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 adecuado. Después de eso, el servicio procesa el mensaje y responde con el resultado teniendo el encabezado de estado HTTP adecuado, por ejemplo 201 - created by success. Para anotar mensajes con metadatos detallados la solución estándar para usar un formato RDF, por ejemplo JSON-LD con un vocab de REPOSO, por ejemplo Hydra y vocabs específicos de dominio como schema.org o cualquier otro vocabulario de datos vinculados y tal vez un vocabulario específico de la 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 se compone de capas jerárquicas. Cada capa contiene componentes que utilizan los servicios de componentes que se encuentran en la siguiente capa a continuación. Por lo tanto, puede 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 una 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 de cliente y el código de servicio no cambiarán.

6. Código en demanda de 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, etc... Para hacer esto, es posible que necesite un sistema de cargador de complementos estándar en el cliente, o su cliente se acoplará a la solución de cargador de complementos.

Las restricciones REST resultan en un sistema altamente escalable en el que los clientes se desacoplan de las implementaciones de los servicios. Así que los clientes pueden ser reutilizables, general al igual que los navegadores en la web. Los clientes y los servicios comparten los mismos estándares y vocabs, 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 en los demás con tareas, al igual que los humanos. Si añadimos patrones de aprendizaje a tales clientes, entonces el resultado será una o más IA usando la web 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 acabados por el Skynet. Hasta entonces ... ;-)

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

1. Recurso (datos, información).
2. Identificador global único (todos los recursos son únicos identificados por URI).
3. Interfaz uniforme - utilice la interfaz simple y estándar (HTTP).
4. Representación - toda la comunicación se hace 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 de red punto a punto simples sobre HTTP que usa verbos como GET, POST, PUT o DELETE implementando arquitectura RESTful que propone la estandarización de la interfaz que cada "recurso" expone. No es nada que el uso de las características actuales de la web en un simple y eficaz (arquitectura altamente exitosa, probada y distribuida). Es una alternativa a mecanismos más complejos como el JABÓN , CORBA and RPC.

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

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

1. Los recursos se solicitan a través de URLs.
2. Los protocolos se limitan a lo que se puede comunicar mediante el uso de URLs.
3. Los metadatos se pasan como pares nombre-valor (datos post 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, hay no se menciona ninguna operación 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 mucha complejidad innecesaria a la interfaz. También requieren marcos adicionales y herramientas de desarrollo para implementarlos. No estoy seguro si el DESCANSO 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.

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

REST (Representational State Transfer) es una arquitectura de diseño que describe cómo se diseñan y abordan los recursos en red (es decir, los nodos que comparten información). En general, una arquitectura RESTful hace que el cliente (el solicitante máquina) y el servidor (la máquina que responde) puede solicitar leer, escribir y actualizar datos sin que el cliente tenga que saber cómo funciona el servidor y el servidor puede devolverlos sin necesidad de saber nada sobre el cliente. Vale, genial...pero, ¿cómo lo hacemos 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 lo que está tratando de hacer con la solicitud y para que el servidor responder.

• Pero para encontrar cualquier recurso dado y luego decirle al cliente dónde vive ese recurso, tiene que haber una forma universal de señalar los recursos. Aquí es donde entran en juego los Identificadores Universales de Recursos (URI); son básicamente direcciones únicas para encontrar los recursos.

Pero el RESTO de la arquitectura no termina ahí! Si bien lo anterior satisface las necesidades básicas de lo que queremos, también queremos tener una arquitectura que soporte tráfico de alto volumen ya que cualquier dado servidor por lo general maneja las respuestas de un número de clientes. Por lo tanto, no queremos abrumar al servidor haciendo que recuerde información sobre solicitudes anteriores.

• Por lo tanto, imponemos la restricción de que cada par 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 una nueva solicitud. Esto significa que queremos nuestras interacciones son apátridas.

• Para aliviar aún más la tensión en nuestro servidor de rehacer cálculos que ya se han hecho recientemente para un cliente dado, 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 proporcionarle la instantánea en lugar de rehacer todos los cálculos necesarios para crear la respuesta inicial. Obstante, dado que es una instantánea, si la instantánea no ha expirado the el servidor establece un tiempo de caducidad por adelantado and y la respuesta se ha actualizado desde la caché inicial (es decir, la solicitud daría una respuesta diferente a la respuesta almacenada en caché), el cliente no verá las actualizaciones hasta que la caché caduque (o la caché se borre) y la respuesta se renderice de nuevo desde cero.

• La última cosa que a menudo aquí sobre las arquitecturas RESTful es que están en capas. Tenemos 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. Por lo tanto, 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 principal a procesar una solicitud con la que el cliente no se comunica directamente. Más bien, el servidor pasa la solicitud como 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 los recursos se pueden señalar usando URLs.

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

Decir que usas el estilo REST es similar a decir que construiste una casa en un estilo particular: por ejemplo, Tudor o victoriano. Tanto el RESTO como un estilo de software y Tudor o victoriano como un estilo doméstico pueden definirse por las cualidades y limitaciones que los componen. Por ejemplo, REST debe tener separación Cliente-Servidor donde se encuentran los mensajes autodescripción. Las casas de estilo Tudor tienen hastiales superpuestos y techos que están inclinados con hastiales frontales. Puede leer la disertación de Roy para aprender más sobre las limitaciones y cualidades que componen el DESCANSO.

REST a diferencia de home styles ha tenido un momento difícil al ser aplicada de manera consistente y práctica. Esto puede haber sido intencional. Dejando su implementación real en manos del diseñador. Así que usted es libre de hacer lo que quiera, siempre y cuando cumpla con las restricciones establecidas en el disertación estás creando Sistemas REST.

Bono:

Toda la web está basada en REST (o REST estaba basada en la web). Por lo tanto, como desarrollador web es posible que desee tener en cuenta que aunque no es necesario escribir buenas aplicaciones web.

Creo que el punto de restful es la separación del estado en una capa superiormientras 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 aquí: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Él 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 restful podría considerarse como una de las soluciones que ha tenido mucho éxito en la práctica actual.

Con estilo restful, obtiene y manipula el estado de la aplicación a través de un Internet poco fiable. Si falla la operación actual para obtener el estado correcto y actual, necesita el principal de validación cero para ayudar a la aplicación a continuar. Si no logra manipular el estado, por lo general utiliza múltiples etapas de confirmación para mantener las cosas correctas. En este sentido, rest no es en sí 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 rest es realmente no atado a Internet o aplicación web. Es una solución fundamental para muchas de las situaciones de programación. Tampoco es simple, solo hace que la interfaz sea realmente simple y hace frente a otras tecnologías increíblemente bien.

Solo mi 2c.

Editar: Dos aspectos más importantes:

• La Apatridia es engañosa. Se trata de la API restful, no de la aplicación o el sistema. El sistema tiene que ser stateful. Diseño restful se trata de diseñar un sistema con estado basado en una API sin estado. Algunas citas de otro QA :

  • REST, opera sobre representaciones de recursos, cada una identificada por una URL. Estos no son típicamente objetos de datos, sino abstracciones de objetos complejos.
  • REST significa "representational state transfer", lo que significa que se trata de comunicar y modificar el estado de algún recurso en un sistema.

• Idempotencia: An a menudo se pasa por alto la parte del RESTO es la idempotencia de la mayoría de los verbos. Eso conduce a sistemas robustos y menos interdependencia de interpretaciones exactas de la semántica.

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

OMI:

1) No hay tal cosa como la programación relajante, sin un gran porro 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 limitaciones. Si su Servicio/Cliente los respeta, entonces es tranquilo. Esto es todo.

Puede resumir (significativamente) las restricciones a:

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

Hay otro post muy bueno que explica las cosas muy bien.

Muchas respuestas copian/pegan información válida mezclándola y añadiendo cierta confusión. La gente habla aquí de niveles, de URIs relajantes(hay no tal cosa!), aplicar métodos HTTP GET, POST, PUT ... El descanso no se trata de eso o no solo de eso.

Por ejemplo enlaces - es bueno tener una API de aspecto hermoso, 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 ser capaz de consumir a cualquier servicio RESTful siempre y cuando se conozca el formato de contenido.

REST significa Representational state transfer.

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

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

Introducción sobre Rest

Hablar es más que simplemente intercambiar información. Un Protocolo está realmente diseñado para que no tenga que ocurrir ninguna conversación. 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 cualquier cambio en las posibles acciones. 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 obtenga dos respuestas diferentes, ya que el estado de la otra parte puede haber cambiado en el ínterin. Hablar es arquitectura RESTful. La tesis de Fielding especifica la arquitectura que uno tendría que seguir si uno quisiera permitir a las máquinas hablar entre sí en lugar de simplemente comunicarse.

No existe tal noción como "programación RESTful" per se. Sería mejor llamarlo 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 de representación (REST) es un estilo arquitectónico utilizado para el desarrollo web.

Vieja pregunta, nueva forma de responder. Hay un montón de ideas erróneas 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 relajante.
2. JSON no es programación restful
3. La programación RESTful no es para APIs

Defino la programación restful como

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

Para ser un programador restful debe estar tratando de construir aplicaciones que permitan a los actores hacer cosas. No solo exponer 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 lo es y cómo ejecutar un control. IE si los navegadores no conocen las etiquetas en html, entonces no habría nada para que usted envíe al estado de transición en su navegador.

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

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

Se debe ingresar una API REST sin ningún conocimiento previo más allá del URI inicial (marcador) y el conjunto de tipos de medios estandarizados que sean apropiados para la audiencia deseada (es decir, se espera que sea entendida por cualquier cliente que pueda usar la API). A partir de ese momento, todas las transiciones de estado de la aplicación deben ser impulsadas mediante la selección por parte del cliente de las opciones proporcionadas por el servidor que están presentes en las representaciones recibidas o implícitas por la manipulación de dichas representaciones por parte del usuario. Las transiciones pueden ser determinadas (o limitadas por) el conocimiento del cliente de los tipos de medios y mecanismos de comunicación de recursos, los cuales pueden ser mejorados sobre la marcha (por ejemplo, código bajo demanda).

[El fallo aquí implica que la información fuera de banda está impulsando 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, Órdenes, 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 el RESTO recurso.

Cada recurso debe soportar las operaciones comunes HTTP. Los recursos se identifican mediante ID globales (que normalmente 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 (content negotiation).

Métodos HTTP:

Los métodos PUT, GET, POST y DELETE son típicos utilizados en arquitecturas basadas en REST. El 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.
• DELETE elimina los recursos. Las operaciones son idempotentes. Pueden repetirse sin producir resultados diferentes.
• POST actualiza un recurso existente o crea un nuevo recurso.

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

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

Decir que Rest es solo un cambio sintáctico de usar peticiones GET con un parámetro action 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 inconsistente resultado.

REST define 6 restricciones arquitectónicas que hacen que cualquier servicio web – a sea una verdadera API RESTful.

1. Interfaz uniforme
2. Cliente-servidor
3. Apátridas
4. Cacheable
5. Sistema de capas
6. Código a petición (opcional)

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

¿Qué es API Testing?

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

API REST

REST: Transferencia de Estado Representacional.

• Es una disposición de funciones en las que los probadores realizan solicitudes y recibir 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 de mensaje estricta, a diferencia de los servicios Web.
• Los mensajes REST a menudo aceptan la forma ya sea en forma de XML, o JavaScript Object Notation (JSON).

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

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. DELETE: – Se utiliza para eliminar un recurso.

Pasos para Probar la API Manualmente:-

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

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

Pasos para automatizar la API REST

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 Restful es la API de uno. Más sobre esto aquí:

Modelo de madurez de Richardson

REST es un estilo de arquitectura de software de sistemas distribuidos (como WWW), se puede imaginar que es una aplicación Web bien diseñada reglas: un grupo de páginas Web de Internet (una máquina de estado virtual), en el que hipervínculo haciendo clic en enlace (transición de estado), el resultado es la siguiente página Web (lo que significa el siguiente estado de la aplicación).

REST describe el sistema de red consta de tres partes:

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

El 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 WWW)
3. Todos los recursos comparten una interfaz uniforme entre el cliente con el estado de transición de recursos, incluir:
   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 puede incluir código ejecutable (es decir, en el Javascript WWW)