Una RESTful API es un estilo arquitectónico para una interfaz de programa de aplicación (API) que utiliza solicitudes HTTP para acceder y usar datos. Esos datos se pueden utilizar para obtener, poner, publicar y eliminar tipos de datos, que se refiere a la lectura, actualización, creación y eliminación de operaciones relacionadas con los recursos.
una API para un sitio web es un código que permite que dos programas de software se comuniquen entre sí. La API detalla la forma adecuada para que un desarrollador escriba un programa que solicita servicios de un sistema operativo u otra aplicación.,
una API RESTful, también conocida como servicio Web REST o API REST, se basa en la transferencia de estado de representación (REST), que es un estilo arquitectónico y un enfoque de las comunicaciones que se usa a menudo en el desarrollo de servicios web.
la tecnología REST es generalmente preferida sobre otras tecnologías similares. Este suele ser el caso porque REST usa menos ancho de banda, lo que lo hace más adecuado para un uso eficiente de internet. Las API RESTful también se pueden construir con lenguajes de programación como JavaScript o Python.,
este artículo es parte de
Guide to building an enterprise API strategy
- que también incluye:
- 5 razones principales para adoptar una plataforma de administración de API
- 10 pautas de seguridad de API y mejores prácticas
- lista de verificación de pruebas de API y mejores prácticas
el resto utilizado por los navegadores idioma de Internet. Con el uso de la nube en aumento, los consumidores de la nube están utilizando las API para exponer y organizar el acceso a los servicios web., REST es una opción lógica para crear API que permiten a los usuarios conectarse, administrar e interactuar con servicios en la nube de manera flexible en un entorno distribuido. Las API RESTful son utilizadas por sitios como Amazon, Google, LinkedIn y Twitter.
cómo funcionan las API RESTful
una API RESTful desglosa una transacción para crear una serie de módulos pequeños. Cada módulo aborda una parte subyacente de la transacción. Esta modularidad proporciona a los desarrolladores mucha flexibilidad, pero puede ser un desafío para los desarrolladores diseñar su API REST desde cero., Actualmente, varias empresas proporcionan modelos para que los desarrolladores los utilicen; los modelos proporcionados por Amazon S3, Cloud Data Management Interface (CDMI) y OpenStack Swift son los más populares.
una API RESTful utiliza comandos para obtener recursos. El estado de un recurso en cualquier marca de tiempo se denomina representación de recursos., Una API RESTful utiliza metodologías HTTP existentes definidas por el protocolo RFC 2616, como:
- GET para recuperar un recurso;
- PUT para cambiar el estado o actualizar un recurso, que puede ser un objeto, archivo o bloque;
- POST para crear ese recurso; y
- DELETE para eliminarlo.
con REST, los componentes en red son un recurso al que el usuario solicita acceso like como una caja negra cuyos detalles de implementación no están claros. Todas las llamadas son apátridas; nada puede ser retenido por el servicio RESTful entre ejecuciones.,
los formatos de datos que admite la API REST incluyen:
- application/json
- application/xml
- application/x-wbe+xml
- application/x-www-form-urlencoded
- multipart/form-data
utiliza
dado que las llamadas son apátridas, REST es útil en aplicaciones en la nube. Los componentes sin estado se pueden redistribuir libremente si algo falla, y se pueden escalar para adaptarse a los cambios de carga. Esto se debe a que cualquier solicitud puede ser dirigida a cualquier instancia de un componente; no puede haber nada guardado que tenga que ser recordado por la siguiente transacción., Eso hace que REST sea preferible para el uso web. El modelo RESTful también es útil en los servicios en la nube porque el enlace a un servicio a través de una API es una cuestión de controlar cómo se decodifica la URL. Es casi seguro que la computación en la nube y los microservicios harán del diseño de API RESTful la regla en el futuro.
RESTful API design and Architecture Constraints
RESTful API design fue definido por el Dr. Roy Fielding en su disertación de doctorado de 2000., Para ser una verdadera API RESTful, un servicio web debe cumplir con las siguientes seis restricciones arquitectónicas REST:
- Uso de una interfaz uniforme (UI). Los recursos deben ser identificables de forma única a través de una única URL, y solo mediante el uso de los métodos subyacentes del Protocolo de red, como DELETE, PUT y GET con HTTP, debe ser posible manipular un recurso.
- basado en cliente-servidor. Debe haber una clara delimitación entre el cliente y el servidor. La interfaz de usuario y las preocupaciones de recopilación de solicitudes son el dominio del cliente., El acceso a los datos, la gestión de la carga de trabajo y la seguridad son el dominio del servidor. Este acoplamiento flexible del cliente y el servidor permite que cada uno se desarrolle y mejore independientemente del otro.
- operaciones sin estado. Todas las operaciones cliente-servidor deben ser apátridas, y cualquier administración de estado que se requiera debe tener lugar en el cliente, no en el servidor.
- almacenamiento en caché de recursos RESTful. Todos los recursos deben permitir el almacenamiento en caché a menos que se indique explícitamente que el almacenamiento en caché no es posible.
- sistema de Capas. REST permite una arquitectura compuesta de múltiples capas de servidores.,
- Código bajo demanda. La mayoría de las veces, un servidor enviará representaciones estáticas de recursos en forma de XML o JSON. Sin embargo, cuando sea necesario, los servidores pueden enviar código ejecutable al cliente.
desafíos comunes de la API REST
Además de las restricciones de diseño y arquitectura, las personas tendrán que enfrentar algunos desafíos con las API REST. Algunos conceptos que pueden ser desafiantes pueden incluir:
- consistencia de endpoints consistency las rutas de endpoints deben ser consistentes siguiendo estándares web comunes, que pueden ser difíciles de administrar.,
- Control de versiones de API’t las URL de endpoint no deben invalidarse cuando se usan internamente o con otras aplicaciones.
- tiempos de respuesta largos y demasiados datos: la cantidad de recursos devueltos puede aumentar de tamaño en el tiempo, lo que se suma a un aumento de los tiempos de carga y respuesta.
- rutas de navegación y ubicaciones de entrada de usuario: debido a que REST utiliza rutas de URL para los parámetros de entrada, determinar los espacios de URL puede ser difícil.,
- Seguridad which que tiene muchos aspectos a tener en cuenta, incluido el uso de:
- HTTPS;
- bloquear el acceso desde direcciones IP y dominios desconocidos;
- validar URL;
- bloquear cargas útiles inesperadamente grandes;
- registrar solicitudes; y
- investigar fallos.
- Authentication use use métodos de autenticación comunes, como la autenticación básica HTTP (que permite una cadena de nombre de usuario:contraseña codificada en base64), claves API, Tokens Web JSON y otros tokens de acceso. OAuth 2.0, por ejemplo, es bueno para el control de acceso.,
- solicitudes y datos may las solicitudes pueden tener más datos y metadatos de los necesarios o pueden ser necesarias más solicitudes para obtener todos los datos. Las API se pueden ajustar para esto.
- API testing can puede ser un proceso largo para configurar y ejecutar. Cada parte del proceso puede ser larga o desafiante. Las pruebas también se pueden hacer en la línea de comandos con la utilidad Curl., Las partes del proceso de prueba que pueden ser difíciles incluyen:
- configuración inicial
- actualizaciones de esquema
- combinaciones de parámetros de prueba
- llamadas a la API de secuencia
- validar parámetros de prueba
- Integración del sistema
- Definir códigos y mensajes de error.
- Con códigos de error, es más una práctica común usar códigos de error HTTP estándar. Estos son reconocidos por los clientes y desarrolladores más a menudo.
- El manejo de errores puede no tener una manera de distinguir si una respuesta es exitosa o no, además de analizar el cuerpo o verificar si hay un error.,
REST vs. SOAP
REST y Simple Object Access Protocol (SOAP) ofrecen diferentes métodos para invocar un servicio web. REST es un estilo arquitectónico, mientras que SOAP define una especificación de protocolo de comunicación estándar para el intercambio de mensajes basado en XML. Las aplicaciones REST pueden usar SOAP.
Los servicios web RESTful son apátridas. Una implementación basada en REST es simple en comparación con SOAP, pero los usuarios deben comprender el contexto y el contenido que se transmite, ya que no hay un conjunto estándar de reglas para describir la interfaz de servicios Web REST., Los servicios REST son útiles para dispositivos de Perfil restringido, como dispositivos móviles, y son fáciles de integrar con sitios web existentes.
SOAP requiere menos código de fontanería, es decir, código de infraestructura de bajo nivel que conecta los módulos de código principales entre sí, que el diseño de servicios REST. El lenguaje de descripción de Servicios Web describe un conjunto común de reglas para definir los mensajes, enlaces, operaciones y ubicación del servicio. Los servicios Web SOAP Son útiles para el procesamiento asíncrono y la invocación.
Historial de API RESTful
antes de REST, los desarrolladores usaban SOAP para integrar las API., Para realizar una llamada, los desarrolladores escribieron a mano un documento XML con una llamada a procedimiento remoto (RPC) en el cuerpo. Luego especificaron el punto final y publicaron su sobre SOAP en el punto final.
en 2000, Roy Fielding y un grupo de desarrolladores decidieron crear un estándar para que cualquier servidor pudiera hablar con cualquier otro servidor. Definió el descanso y las limitaciones arquitectónicas explicadas anteriormente en su tesis doctoral de 2000 en la Universidad de California, Irvine. Estas reglas universales hacen que sea más fácil para los desarrolladores integrar software.,
Salesforce fue la primera compañía en vender una API como parte de su paquete» Internet as a Service » en 2000. Sin embargo, pocos desarrolladores fueron capaces de utilizar la complicada API XML. Luego eBay construyó una API REST, que expandió su mercado a cualquier sitio que pudiera acceder a su API. Esto llamó la atención de otro gigante del comercio electrónico, y Amazon anunció su API en 2002.
Flickr lanzó su propia API RESTful en agosto de 2004, permitiendo a los bloggers incrustar fácilmente imágenes en sus sitios y feeds de redes sociales., Facebook y Twitter lanzaron sus API en 2006, cediendo bajo la presión de los desarrolladores que rasparon los sitios y crearon las API de «Frankenstein». Cuando Amazon Web Services (AWS) ayudó a lanzar la nube en 2006, los desarrolladores pudieron acceder al espacio de datos en minutos utilizando la API REST de AWS, y la solicitud de API públicas aumentó rápidamente.
desde entonces, los desarrolladores han adoptado las API RESTful, usándolas para agregar funcionalidad a sus sitios web y aplicaciones. Hoy en día, las API REST se consideran la » columna vertebral de internet.»
