Pregunta ¿Qué es exactamente la programación RESTful?


¿Qué es exactamente la programación RESTful?


3628
2018-03-22 14:45


origen


Respuestas:


Un estilo arquitectónico llamado REST (Transferencia de estado representacional) defiende que las aplicaciones web deberían usar HTTP tal como era originalmente previsto. Las búsquedas deberían usar GET peticiones. PUT, POSTy DELETE peticiones debe ser utilizado para mutación, creación y eliminación respectivamente.

Los defensores de REST tienden a favorecer a 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 se deben usar para actualizar la información. Por ejemplo, una solicitud GET para agregar un artículo a un carro

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

no sería apropiado Las solicitudes GET deben ser idempotente. 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 almacenables. La solicitud de "agregar al carrito" no es idempotente; emitirla dos veces agrega dos copias del artículo al carro. 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 Caras de JavaServer libro de David M. Geary.


540
2018-04-15 11:26



DESCANSO 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 maneras 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 acordar el medios de comunicación utilizado, que en el caso de la web es HTML.

Una API que se adhiere a los principios de DESCANSO no requiere que el cliente sepa nada sobre la estructura de la API. Más bien, el servidor debe proporcionar la información que el cliente necesita para interactuar con el servicio. Un Forma 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 debe enviar. Ambas formas de información son completamente provistas por el servidor. (Este principio se llama HATEOAS: Hipermedia como motor del estado de aplicación.)

Entonces, ¿cómo se aplica esto a HTTPy cómo se puede implementar en la práctica? HTTP está orientado en torno a verbos y recursos. Los dos verbos en el 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 que es administrada por un servicio web. Nuestro servicio utiliza un hipermedio personalizado basado en JSON, para el cual le asignamos el tipo mimet application / json + userdb (También puede haber un application / xml + userdb y aplicación / lo que sea + userdb - muchos tipos de medios pueden ser compatibles). Tanto el cliente como 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 debe gastar casi todo su esfuerzo descriptivo en   definir los tipos de medios utilizados para representar recursos y conducir   estado de la aplicación, o al definir 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 a partir de secciones llamadas "enlaces". Se llama Controles hipermedia. En este caso, podemos decir a partir de dicha sección que podemos encontrar una lista de usuarios haciendo otra solicitud de /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 para /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 suponemos en la parte de clientes es nuestra definición de medios.

Otras lecturas:

(Esta respuesta ha sido objeto de una buena cantidad de críticas por no entender el punto. En su mayor parte, ha sido una crítica justa. Lo que originalmente describí estaba más en consonancia con la forma en que el REST solía implementarse hace unos años cuando primero escribí esto, en lugar de su verdadero significado. He revisado la respuesta para representar mejor el significado real).


2788
2018-03-22 19:37



La programación REST se trata de:

  • recursos identificados por un identificador persistente: los URI son la elección omnipresente de identificador en estos días
  • recursos que se manipulan 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 POST, GET, PUTy DELETE. Pero REST no se limita a HTTP, sino que es 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 Aceptar para controlar si desea que 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 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 / reutilizar de manera consistente: uso de encabezados de control de caché HTTP

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 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 acerca de la arquitectura y la capacidad de almacenamiento en caché de los recursos que de HTTP.

Si está realmente interesado en qué es una arquitectura RESTful y por qué funciona, lea su tesis unas pocas veces y lea el toda la cosa ¡No solo el Capítulo 5! Siguiente mirada en 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é DNS. Finalmente, lea las especificaciones HTTP (RFC2616 y RFC3040 en particular) y considerar cómo y por qué el almacenamiento en caché funciona de la manera en que lo hace. Eventualmente, solo 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 en comprender por qué las interfaces SOA y Message Passing son escalables.

Creo que el truco más importante para entender la importancia arquitectónica y las implicaciones de rendimiento de un RESTful y Nada compartido arquitecturas es evitar colgarse de 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, los protocolos y las tecnologías.


500
2017-07-04 05:47



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 en consecuencia lname y age será NULL):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



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

Debe leer son Representational State Transfer (REST) y Las API REST deben estar basadas en hipertexto 

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

Richardson Maturity Model

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 la RMM, leer el artículo para detalles o diapositivas de la charla qcon.

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

...

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

REST Prueba de tornasol para marcos web es una prueba de madurez similar para marcos web.

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

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

DESCANSO y versionado discute extensibilidad, control de versiones, evolucionabilidad, etc.  a través de Modificabilidad


170
2018-03-22 15:20



¿Qué es REST?

REST significa Transferencia de estado representacional. (Lo es a veces   deletreado "ReST"). Se basa en un servidor sin estado, cliente-servidor, cacheable   protocolo de comunicaciones, y en prácticamente todos los casos, el HTTP   protocolo es usado.

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

En muchos sentidos, la World Wide Web en sí misma, 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 (por ejemplo, realizar consultas),   y borrar datos. Por lo tanto, REST usa HTTP para los cuatro CRUD   (Crear / Leer / Actualizar / Eliminar) operaciones.

REST es una alternativa ligera a mecanismos como RPC (Remote   Llamadas a procedimientos) y servicios web (SOAP, WSDL, et al.). Más tarde, lo haremos   ver cuánto más REST simple es.

A pesar de ser simple, REST tiene todas las funciones; básicamente hay   nada que pueda hacer en los servicios web que no se puede hacer con un RESTful   arquitectura. REST no es un "estándar". Nunca habrá un W3C   recomendacion para REST, por ejemplo. Y mientras hay DESCANSO   los marcos de programación, trabajar con REST es tan simple que usted puede   a menudo "hazlo tu mismo" con características 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/


128
2018-03-22 14:53



REST está utilizando varios 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), enviaría una solicitud DELETE a la /user/[id] URL, para editar un usuario, para recuperar información de 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 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

Usas los "verbos" HTTP y tienes ...

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

85
2017-07-12 16:33