¿Qué es exactamente la programación RESTful?

3983

¿Qué es exactamente la programación RESTful?

Hasen
fuente
3
vea también la respuesta en el siguiente enlace stackoverflow.com/a/37683965/3762855
Ciro Corvino
3
REST podría estar un poco viejo ahora;) youtu.be/WQLzZf34FJ8
Vlady Veselinov
1
Además, consulte este enlace para obtener más información news.ycombinator.com/item?id=3538585
Ashraf.Shk786
55
@ OLIVER.KOO buena observación. Es solo que lo pregunté en un momento en que era algo nuevo. Se estaba tirando mucho, pero no mucha gente sabía de qué se trataba. Al menos no lo hice, y parece que preguntar esto les ha ayudado porque también querían saberlo.
hasen

Respuestas:

743

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.

Shirgill Farhan
fuente
2
Listado de operaciones idempotentes disponibles: GET (Safe), PUT & DELETE (La excepción se menciona en este enlace restapitutorial.com/lessons/idempotency.html). Referencia adicional para métodos seguros e idempotentes w3.org/Protocols/rfc2616/rfc2616-sec9.html
Abhijeet
55
a) el punto importante sobre GET es la seguridad, no la idempotencia, b) @Abhijeet: RFC 2616 ha quedado obsoleto en 2014; ver RF 7230ff.
Julian Reschke
12
Esto está mal. Lea esto para una interpretación correcta de REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven o este stackoverflow.com/questions/19843480/…
kushalvm
44
@kushalvm Esa definición académica de REST no se usa en la práctica.
Warlike Chimpanzee
3
Efectivamente, podemos preguntarnos si un concepto está operativo, ya que no logramos darle una definición estable y comprensible para todos
HoCo_
2918

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:

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

Emil H
fuente
178
No. REST no solo apareció como otra palabra de moda. Surgió como un medio para describir una alternativa al intercambio de datos basado en SOAP. El término REST ayuda a enmarcar la discusión sobre cómo transferir y acceder a los datos.
tvanfosson
111
Sin embargo, el corazón de REST (en la aplicación práctica) es "no use GET para hacer cambios, use POST / PUT / DELETE", que es un consejo que he estado escuchando (y siguiendo) desde mucho antes de que apareciera SOAP. REST siempre ha estado allí, simplemente no recibió un nombre más allá de "la forma de hacerlo" hasta hace poco.
Dave Sherohman
37
No olvide "Hipertexto como motor del estado de la aplicación".
Hank Gay
45
Esta respuesta pierde el punto. HTTP apenas se menciona en la tesis de Fielding.
user359996
18
Esta respuesta no menciona el propósito de REST, y hace que parezca que todo se trata de URI limpios. Si bien esta podría ser la percepción popular de REST, las respuestas de D.Shawley y oluies son más precisas: se trata de poder aprovechar las características integradas en la arquitectura, como el almacenamiento en caché, trabajando con ella en lugar de en contra de ella. Los URI más bonitos son principalmente un efecto secundario común.
TR
534

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.

D.Shawley
fuente
36
Una respuesta que proporcione una lista de lectura es muy apropiada para esta pregunta.
ellisbben 01 de
25
Gracias por la actualización. PUTy POSTrealmente no mapees uno a uno con actualizar y crear. PUTse puede usar para crear si el cliente está dictando cuál será el URI. POSTcrea si el servidor está asignando el nuevo URI.
D.Shawley
8
No olvides PARCHE.
epitka
44
Una URN es un URI que usa el urn:esquema. Conceptualmente no hay diferencia; sin embargo, una URN requiere que tenga un método definido por separado para "localizar" el recurso identificado (nombrado) por la URN. Se debe tener cuidado para asegurarse de no introducir un acoplamiento implícito al relacionar los recursos nombrados y su ubicación.
D.Shawley
2
@ellisbben De acuerdo. Si entiendo correctamente, esta es la disertación que dio lugar a REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Philip Couling
408

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
Pbreitenbach
fuente
39
Para mí, esta respuesta capturó la esencia de la respuesta deseada. Simple y pragmático. Por supuesto, hay muchos otros criterios, pero el ejemplo proporcionado es una gran plataforma de lanzamiento.
CyberFonic
92
En el último ejemplo, @pbreitenbach usa PUT fname=Jonny. Esto establecería lnamey agea los valores predeterminados (probablemente NULL o la cadena vacía, y el número entero 0), debido a que un PUT sobrescribe la totalidad del recurso con los datos de la representación proporcionada. Esto no es lo que implica "actualizar", para hacer una actualización real, use el PATCHmétodo ya que esto no altera los campos que no están especificados en la representación.
Nicholas Shanks el
24
Nicholas tiene razón. Además, el URI para la primera POST que crea un usuario debe llamarse usuarios porque /user/1no tiene sentido y debe haber una lista en /users. La respuesta debe ser ay 201 Createdno solo en ese caso.
DanMan
1
Este es solo un ejemplo de una API no necesariamente una API RESTful. Un RESTful tiene restricciones a las que se adhiere. Arquitectura cliente-servidor, sin estado, capacidad de caché, sistema en capas, interfaz uniforme.
Radmation
Esa es una respuesta muy compacta que cubrió todos los métodos de acceso de servlet http
Himanshu Ahuja
181

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.

Modelo de madurez de Richardson

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

oluies
fuente
55
Creo que esta respuesta toca el punto clave de entender REST: qué significa la palabra representacional . Nivel 1 - Recursos dice sobre el estado . Nivel 2 - Verbos HTTP dice acerca de la transferencia ( cambio de lectura ). Nivel 3: HATEOAS dice impulsar futuras transferencias a través de la representación (JSON / XML / HTML devuelto), lo que significa que ya sabe cómo decir la próxima ronda de conversación con la información devuelta. Entonces REST lee: "(representacional (transferencia de estado))", en lugar de "(transferencia (estado de representación))".
lcn
136

¿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/

Ravi
fuente
Esta es una respuesta realmente concisa. ¿Puedes describir también por qué REST se llama apátrida?
Chaklader Asfak Arefe
89

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
dbr
fuente
18
Eso es "usar HTTP correctamente", lo que no es lo mismo que "descansar" (aunque está relacionado con eso)
Julian Reschke
2
También podría usar / user / del / 2 y / user / remove / 2 o ... GET / DELETE / PUT / POST son solo la forma estandarizada y "adecuada" de hacer tales cosas (y como dice Julian, eso no es todo hay que DESCANSAR)
dbr
1
Claro, pero esa no es razón para evitarlos. REST simplemente te ahorra reinventar la rueda cada vez. Para una API REST es grande (consistencia!), Pero para la estructuración de un sitio web al azar que en realidad no importa que diría (que puede ser más problemas de lo que vale)
DBR
14
Vadim, eso sería simplemente RPC. También es peligroso usar GET para modificar datos, ya que (entre otras razones) un motor de búsqueda puede arañar sus enlaces de eliminación y visitarlos a todos.
aehlke
77
@aehlke - Creo que la verdadera pregunta sería "¿Por qué un usuario anónimo tiene la capacidad de eliminar registros de su sistema?"
Spencer Ruport
68

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.

Hank Gay
fuente
2
pero no directo ... lo hace más complicado de lo que debe ser.
hasen
44
Además, aunque los términos REST y RESTful se usan casi exclusivamente en el ámbito de las aplicaciones web en este momento, técnicamente no hay nada que vincule REST a HTTP.
Hank Gay
3
El blog de fildeo tiene algunos buenos, más fácil a los artículos Comprender las relativas al descanso y conceptos erróneos comunes: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
aehlke
3
@HankGay Creo que la razón por la que no es más esotérico es que la mayoría de los desarrolladores de servicios web ven REST como una maravillosa simplificación sobre alternativas como SOAP. No se limitan necesariamente a obtener todos los tecnicismos REST correctos, y eso probablemente enloquece a los fanáticos de REST, pero en la mayoría de los casos probablemente no tengan que preocuparse por cosas como asegurarse de que sus resultados estén "habilitados para hipermedia".
moodboom
47

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.

Sólo tu
fuente
Este artículo explica la relación entre HTTP y REST freecodecamp.org/news/…
Only You
45

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

tompark
fuente
12
enlaces geniales, gracias. Estoy cansado de estos tipos REST que dicen que algún ejemplo no es "REST-ful", pero luego se niegan a decir cómo cambiar el ejemplo para que sea REST-ful.
coder_tim 01 de
38

¿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
Suresh Gupta
fuente
1
Que Communication is Done by Representationsignifica
mendez7
33

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.

Conocer
fuente
77
entonces ... ¿cómo sería ese ejemplo tranquilo? ¿Cómo cambiarías la url para que sea reparadora?
hasen
1
hasen: Usar un recurso para todas las operaciones puede ser necesario para RESTfulness, pero no es suficiente .
Ken
18
ok bien .. ¿podrías explicar más? ¿Cuál es el punto de decir "no, estos tipos están equivocados ... sé lo que está bien" sin decir lo que sabes (o piensas) que tiene razón?
hasen
55
Le di el enlace a la descripción de Fielding. Pensé que dije exactamente la diferencia relevante a las otras respuestas: necesita ser impulsada por el hipertexto. Si "/ user / 123" proviene de alguna documentación de API fuera de banda, entonces no es RESTful. Si proviene de un identificador de recurso en su hipertexto, entonces lo es.
Ken
1
O puede usar un punto de entrada como / users / y le dará una lista de recursos de usuario Y el URI para cada uno. Luego, los recursos son reconocibles y la navegación está impulsada por el hipertexto.
aehlke
26

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

inf3rno
fuente
22

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.

kenorb
fuente
17

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.

Nathan Andelin
fuente
17

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.

demandando
fuente
17

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.

Kal
fuente
15

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:

minghua
fuente
1
Un punto de vista MVC : el blog Rest Worst Practices sugirió no combinar modelos y recursos . El libro Two Scoops de django sugiere que la API Rest es la vista, y no mezclar la lógica de negocios con la vista. El código de la aplicación debe permanecer en la aplicación.
minghua
1
Otro buen artículo: WikiPedia sobre Arquitectura Orientada a Recursos
minghua
14

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.

Kalin
fuente
14

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

modelo de madurez de richardson anotado

Chris DaMour
fuente
11

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

lokesh
fuente
no responde la pregunta tan bien como las demás, ¡pero +1 para información relevante!
CybeX
Creo que esto también responde a la pregunta, pero por ejemplo falta la apatridia. Cada restricción es importante ... La parte del tipo de medio estándar no siempre es verdadera. Quiero decir que hay capas de comprensión. Por ejemplo, si usa RDF, se puede entender el tipo de medio, pero no el significado del contenido. Por lo tanto, el cliente también necesita conocer el vocabulario. Algunas personas están experimentando con este tipo de API REST y un vocabulario REST general para describir hipervínculos, etc. hydra-cg.com
inf3rno
11

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.
Imran Ahmad
fuente
Varias citas, pero ni una sola fuente mencionada. ¿De dónde has sacado esto?
djvg
10

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

GowriShankar
fuente
10

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 .

qmckinsey
fuente
10

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.

ACV
fuente
9

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.

Benoit Essiambre
fuente
55
"Decir que el descanso es solo un cambio sintáctico ... hace que parezca que no tiene beneficios y es puramente cosmético" --- es exactamente por eso que estoy leyendo las respuestas aquí en SO. Tenga en cuenta que no explicó por qué REST no es puramente cosmético.
osa
5

¿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

kkashyap1707
fuente
55
esta ni siquiera es una respuesta adecuada
2016
5

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

Krishna Ganeriwal
fuente
Si observa las restricciones que Fielding puso en REST, verá claramente que una API debe haber alcanzado la capa 3 del RMM para ser vista como RESTful, aunque esto simplemente no es suficiente en realidad, ya que todavía hay suficientes posibilidades para fallar el Idea REST: el desacoplamiento de clientes de las API del servidor. Claro, la capa 3 cumple con la restricción HATEOAS, pero aún es fácil romper los requisitos y acoplar a los clientes estrechamente a un servidor (es decir, mediante el uso de recursos escritos)
Roman Vottner
2

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.

Kürsat Aydinli
fuente