Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuál es la diferencia entre REST y RESTful?

 

Es muy poco probable que haya alguien en el espacio de API que no esté al menos tangencialmente consciente de REST , los principios establecidos por Roy Fielding en 2000 que inspiraron el estándar de diseño de API moderno . Sin embargo, aunque la mayoría de las personas están familiarizadas con términos como REST, REST-like y RESTful , es posible que la diferencia entre ellos no sea evidente de inmediato.

La versión corta de esto es que REST es un estilo arquitectónico y las API REST son servicios web que lo implementan. Sin embargo, para complicar las cosas, los desarrolladores llaman a una API web HTTP utilizando un estilo CRUD que es principalmente (pero no al 100%) REST un servicio RESTful .

En otras palabras, no es tan simple como "REST es el sustantivo y RESTful es el adjetivo".

Entonces, ¿se pueden usar los términos indistintamente? En la mayor parte. Pero eso no significa que deban serlo. A continuación, analizaremos más de cerca los orígenes y el uso recomendado de REST y RESTful. También profundizaremos en las sutiles diferencias entre la terminología REST.

Definir: DESCANSO (e Historial)
Empecemos con lo básico. REST significa Transferencia de Estado REpresentacional y es un estilo arquitectónico compuesto por varios principios:

  • Sin estado : las aplicaciones REST deben ser apátridas.
  • Cliente-Servidor (Separación) : La modificación independiente de estos componentes es esencial.
  • Sistema en capas : los componentes de los sistemas REST no deben poder ver más allá de su capa.
  • Almacenable en caché : los datos del servidor REST deben marcarse como almacenables en caché o no.
  • Interfaz uniforme : se hace hincapié en una interfaz uniforme entre los componentes.
Esbozado en la disertación de Roy Fielding en 2000, tomó un tiempo para que REST fuera apodado el "asesino de SOAP" que más tarde llegó a ser visto. Diseñado para ser más fácil de usar y más flexible que SOAP , la adopción temprana por eBay y Amazon habló del brillante futuro de REST.

En los próximos años, REST se convertiría en un estilo arquitectónico dominante en el espacio API. Si está desarrollando una API en 2021, con muy pocas excepciones, una comprensión profunda del diseño de la API REST es una de las herramientas más esenciales que querrá tener a su disposición.

Aunque hay muchas mejores prácticas de API como…

  • Accede a los recursos del servidor usando URI
  • Utiliza solo el protocolo HTTP (y verbos como GET, POST, PUT y DELETE para operaciones CRUD)
  • Devuelve resultados en forma de JSON o XML, atom, OData, etc.
Existen y están asociados con REST, no todo ha sido definido explícitamente por Fielding. De hecho, gran parte de lo que compone REST siempre se ha definido de manera bastante vaga.

Sin embargo, en referencia a la restricción de "Interfaz uniforme" mencionada anteriormente, HATEOAS (Hypermedia as the Engine of Application State) es una restricción clave de la arquitectura de la aplicación REST. Sin embargo, también es uno que muchos desarrolladores no creen que sea necesario ... lo que lleva al resultado RESTful .

Definir: RESTful (y basado en REST, REST-ish)
Como ya se mencionó anteriormente, una API que se describe como RESTful adopta y se adhiere a los principios de la arquitectura REST. Sin embargo, lo que podría no hacer es ajustarse a las limitaciones de HATEOAS: Roy Fielding argumentó en 2008 que las API REST deben estar impulsadas por hipertexto.

Es posible que vea que algunos proveedores proclaman que sus servicios están basados ​​en REST o en REST. Esto suele ser una abreviatura para seguir algunos, pero no todos, los principios descritos por REST. Como hemos visto anteriormente, es más probable que RESTful se use para describir servicios que siguen todos, o casi todos, los principios de REST.

Por cierto, hay varias razones por las que un servicio podría necesitar desviarse de tener una arquitectura REST, por lo que no es necesario descartar el basado en REST como inferior o no válido. Sin embargo, vale la pena observar qué principios sigue o no sigue y cómo eso podría afectar la implementación.

Ya en 2017, el 83% de las API públicas eran "API REST" en comparación con el 15% que eran API SOAP. Pero quizás el uso de ese término en este contexto sea engañoso. Debido a que REST se refiere a restricciones arquitectónicas y es independiente del lenguaje y la plataforma, no existe una imagen simple y directa de cómo debería verse una "API REST". Números como los anteriores probablemente también incluyan servicios RESTful y REST-ish / REST.

Aun así, no se puede negar que el desarrollo de la API REST ha logrado (y mantiene) el dominio en el espacio. También está claro que su principal oposición ya no es SOAP, sino el GraphQL más nuevo y elegante .

El futuro de REST / RESTful
En 2020, observamos que el 82% de las API eran RESTful (OpenAPI / Swagger) y el 21% eran RESTful (no OpenAPI / Swagger), mientras que el 19% usaba GraphQL. Vale la pena señalar que GraphQL no es un "competidor" directo de REST, ya que es un lenguaje en lugar de un estilo arquitectónico. A pesar de eso, algunos lo han promocionado como una alternativa a las API REST desde su introducción por Facebook.

Hay una gran cantidad de artículos de " DESCANSO en paz ", que es un buen juego de palabras para ser justos. Muchos de ellos sugieren, o no llegan a sugerir, que GraphQL hará que REST sea irrelevante.

Bueno, ahora estamos en 2021 y eso aún no ha sucedido.

Según los números citados anteriormente, el uso de la arquitectura REST en las API públicas solo se ha reducido en un punto porcentual más o menos. Eso no es sorprendente, dado que la revisión de una API requiere una enorme cantidad de desarrollo y no es algo que deba tomarse a la ligera.

Queda por ver si GraphQL, o algún otro nuevo enfoque emocionante para el desarrollo de API, desbancará al desarrollo de REST en los próximos años. Sin embargo, por ahora, REST sigue siendo supremo, por lo que no es necesario eliminar todas sus API RESTful todavía.

Publicar un comentario

0 Comentarios