El intercambio de datos entre múltiples plataformas es más crucial que nunca en la era de las integraciones. Piense en una tienda online sin integraciones. Su sitio web tendría que desarrollar sistemas para gestionar las cuentas de los usuarios, las suscripciones por correo electrónico, el procesamiento de los pagos, los envíos y otras tareas, además de gestionar los listados de productos. Sería más eficaz subcontratar estas tareas a otros proveedores, ya que no es una opción escalable.
Lasinterfaces de programación de aplicaciones, o API web, son las que utilizan los programas de software para comunicarse entre sí. Las API ofrecen un protocolo coherente para el intercambio de datos entre dos programas. Con la ayuda de las API web, su tienda online puede comunicarse con el software de entrega, las aplicaciones de los clientes, las aplicaciones de pago y cualquier otra conexión necesaria.
Hay varias formas de crear una API; sin embargo, si quiere añadir conexiones de software a sus servicios, hay una técnica única con la que debería estar familiarizado: Los servicios web REST APIs. En este artículo, hablaremos de ejemplos de API REST, de lo que es una API REST, de cómo funcionan las API REST, de para qué se utilizan las API REST, de su historia, de sus elementos y de mucho más.
¿Qué es exactamente una API REST?
Los servicios web de transferencia de estado representacional o APIs REST son la práctica más estándar para vincular componentes en marcos de microservicios porque ofrecen una forma versátil y portátil de incorporar aplicaciones. REST es un diseño de API muy popular que se emplea para interactuar con las partes interesadas internas y externas de una manera estandarizada y predecible.
Los usuarios de aplicaciones web emplean con frecuencia servicios web de APIs REST para comunicarse entre sí. Por ejemplo, para adquirir y revisar los detalles de una cuenta en un programa de redes sociales. Los navegadores de las APIs REST pueden verse como la sintaxis de la web. Los clientes online utilizan las APIs web para proporcionar y gestionar el acceso a las operaciones digitales a medida que aumenta el uso de la nube.
Diseñar APIs web que permitan a los clientes conectarse, administrar y relacionarse con servicios web digitales de forma dinámica en un contexto disperso es una decisión sensata. Sitios web como Google, eBay, Facebook, Amazon y Twitter emplean servicios web RESTful. Las aplicaciones cliente pueden ahora utilizar REST para acceder a estos servicios web.
La tecnología REST se ve favorecida sobre otras tecnologías relacionadas. Esto se debe a que los servicios web REST consumen menos ancho de banda, lo que los hace ideales para una actividad online efficient. Los servicios web RESTful también pueden desarrollarse utilizando lenguajes de programación como JavaScript o Python.
¿Cómo funcionan las APIs REST?
Para saber cómo funcionan las APIs REST, debemos definir algunos términos clave:
Cliente
Un usuario de la API se denomina cliente. El cliente envía consultas a las APIs web para obtener datos o aplicar modificaciones al programa. Su navegador de Internet es un cliente; se comunica con varias APIs web para obtener el contenido de la página. Su ordenador recibe la información requerida, que luego se muestra en la pantalla.
A continuación se detallan los métodos HTTP más populares:
- Utilizar la petición GET para devolver los datos solicitados o los recursos solicitados.
- Utilizar la petición POST para hacer un nuevo recurso
- Utilice la instrucción PUT para realizar cambios o seguir actualizando un recurso existente
- Utilizar la instrucción DELETE para deshacerse de un recurso.
Por ejemplo, una solicitud HTTP a la API de Youtube podría ser un recurso de solicitud GET para un vídeo o una publicación en particular o una solicitud POST para publicar una nueva foto. El método de solicitud POST se puede utilizar para publicar nuevos posts. Del mismo modo, una plataforma de servicios web para clientes que se integre con una implementación de asistentes automáticos puede emplear la instrucción PUT para actualizar o eliminar un hola personalizado.
Petición Get
- Es posible el almacenamiento en caché de las peticiones GET. El historial del navegador incluye las peticiones GET.
- Es posible marcar las solicitudes GET.
- No utilice nunca peticiones GET mientras trabaje con material crítico.
- Las solicitudes GET tienen limitaciones de longitud.
- Sólo se realizan consultas de datos a través de peticiones GET
El método POST
La petición POST es un método de envío de información a un servidor para añadir o actualizar recursos. El cuerpo de una petición HTTP contiene los datos que se publican en el lado del servidor:
- Las peticiones POST del método post nunca van a la caché.
- Las peticiones POST no se almacenan en el historial del navegador.
- Las peticiones POST no se pueden marcar como favoritos
Cuerpo de la respuesta
El cuerpo de la respuesta es uno de los elementos importantes de la API RESTful. Los datos solicitados se incluyen en el cuerpo de la respuesta. El cuerpo de la respuesta puede incluir datos relativos a los puertos de salida y a la lógica de salida.
Recurso
Cualquier dato que las APIs de la web puedan dar al usuario es un recurso. Por ejemplo, una persona, una página, una imagen o un comentario pueden considerarse recursos en la API de Facebook. El identificador de recurso es un término especial que se da a cada recurso.
Servidor web
El programa que acepta el cuerpo de la solicitud del cliente utiliza un servidor web, que alberga los recursos que el consumidor solicita. El servidor puede comunicarse con los clientes a través de una API sin ofrecer a los clientes acceso inmediato a la información guardada en sus bases de datos. Cuando un usuario accede a los servicios web RESTful para enviar un cuerpo de solicitud, el servidor envía una representación normalizada del estado del recurso al navegador.
Esto significa que, de alguna manera, el servidor no envía el recurso exacto al cliente, sino que refleja su estado, es decir, la situación del recurso en un momento determinado. Para facilitar la comprensión, las respuestas se devuelven en un formato ligero.
El formato JSON (JavaScript Object Notation) es muy utilizado, ya que es legible tanto para las personas como para las máquinas, y es excelente para ayudar a promover la accesibilidad de la web. JSON se utiliza principalmente para enviar el cuerpo de la solicitud en las aplicaciones web y en las aplicaciones cliente. Es un formato compatible con una gran variedad de codificación. Los formatos de datos de la API distintos de JSON incluyen XML, YAML, CSV, HTML y texto plano. Los usuarios de las APIs pueden seleccionar cualquier formato de datos que deseen utilizando tipos de medios personalizados.
Historia de las APIs REST
Muchos programadores tuvieron que trabajar con SOAP antes que con REST para incorporar las APIs. Construir, utilizar y depurar SOAP eran tareas notoriamente difíciles. Afortunadamente, REST fue desarrollado por un equipo de programadores bajo la dirección de Roy Fielding, alterando para siempre el entorno de las API.
He aquí una cronología del desarrollo de las APIs REST a lo largo del tiempo:
Antes de REST
Los programadores escribían manualmente un archivo XML que contenía una llamada a procedimiento remoto (RPC) dentro del contenido para conectar las APIs de la web usando SOAP. Después, los diseñadores enviaban su paquete SOAP al punto final especificado.
En el año 2000
un equipo de programadores dirigido por Roy Fielding decidió desarrollar un marco que permitiera a cualquier servidor comunicarse con cualquier otro. Estableció las restricciones para las APIs REST. Como estas directrices son universales, el desarrollo de software es más fácil.
En el año 2002
eBay desarrolló su API RESTful en 2002, abriendo su mercado a cualquier sitio web que pudiera beneficiarse de él. Debido a esto, otro titán del comercio electrónico, Amazon, se interesó por ella y, en 2002, lanzó su API RESTful.
En el año 2004-2006
En 2004 se lanzaron los servicios web RESTful de Flickr, que permitían a los escritores añadir rápidamente fotografías a sus sitios web y a sus publicaciones en las redes sociales. Cuando Twitter y Facebook se dieron cuenta de que un número importante de programadores estaban escudriñando los sitios web y haciendo APIs "Frankenstein", ambos expusieron sus APIs unos dos años después.
En el año 2006-Presente
Los servicios web RESTful son ahora ampliamente aceptados por los programadores, que utilizan estos servicios web RESTful para mejorar el rendimiento de sus aplicaciones y sitios. AppMaster facilita la cooperación y hace más fácil la construcción de APIs, permitiéndole hacerlo más rápidamente.
¿Para qué se utilizan las APIs REST?
Uno de los principales beneficios de los servicios web RESTful es que ofrece una gran flexibilidad, lo que le permite utilizar esta API RESTful de manera más eficaz. A continuación se muestran algunos ejemplos de para qué se utilizan las APIs REST.
Aplicaciones basadas en la nube
Debido a la ausencia de estado de sus llamadas, las APIs REST son ventajosas en las aplicaciones en la nube. Los módulos sin estado pueden reinstalarse fácilmente y crecer para satisfacer la necesidad de capacidad si algo va mal. Un programa de software que combina componentes locales y basados en Internet es una aplicación en la nube. Este paradigma utiliza servidores distantes a los que se accede mediante un navegador web y servicios web de Internet en curso para ejecutar las instrucciones.
La ubicación tradicional de los hosts de aplicaciones en la nube es un sistema informático distante gestionado por un operador de red de computación en la nube de terceros. El correo, la compartición y el almacenamiento de documentos, la introducción de pedidos, el control de inventarios, Microsoft Word, la gestión de las relaciones con los clientes(CRM), la recopilación de información y las finanzas y la contabilidad son ejemplos de trabajos realizados con aplicaciones basadas en la nube.
Las interfaces de programación de aplicaciones(API) REST pueden utilizarse para conectar fuentes externas de información y recursos de almacenamiento. Los programadores pueden hacer que las aplicaciones en la nube sean más pequeñas utilizando las API REST para transferir datos a otros programas para manejar o analizar cálculos y devolver los resultados al programa de software. Las APIs probadas refuerzan la uniformidad activa, lo que puede acelerar la producción y producir resultados reales.
Un ejemplo de aplicación en la nube es Google Docs u Office 365. Todo lo que se requiere para Google Docs u Office 365 es un ordenador que pueda ejecutar motores de búsqueda y servicios web de Internet. Las redes informáticas proporcionan la interfaz de usuario y las operaciones, incluido el almacenamiento de información. Su empresa puede alojar numerosas y distintas aplicaciones en la nube mediante hosts de aplicaciones en la nube.
Servicios en la nube
Dado que es necesario gestionar cómo se procesa la URL para conectarse a un recurso a través de una API, las API REST también son útiles para los servicios web en la nube. Es probable que la arquitectura de servicios web RESTful se convierta en un estándar en el futuro debido a las aplicaciones en la nube. Los programadores utilizan los servicios web RESTful para conectarse a los servicios en la nube utilizando Internet. Un desarrollador crea un código que utiliza la API del proveedor de Internet, da las entradas y variables necesarias y luego comprueba la respuesta para asegurarse de que la acción funciona como se espera.
Los usuarios finales pueden acceder a las aplicaciones cliente o a los servicios web ofrecidos por los servicios web en la nube, como la infraestructura informática, los sistemas de almacenamiento o los sistemas de seguimiento, utilizando un servicio en la nube como los servicios web RESTful. Las APIs describen las capacidades y operaciones de una aplicación y los detalles necesarios para llevarlas a cabo. Para mantener la privacidad y la seguridad de los clientes, las API suelen depender de la interoperabilidad de REST o del Protocolo Simple de Acceso a Objetos (SOAP) y de mecanismos de permiso como OAuth 2.0.
Una serie de servicios web se denominan "servicios en la nube" y se ponen a disposición de las empresas y los consumidores en línea a petición. Estos servicios web se crean para ofrecer un acceso rápido y económico a herramientas y aplicaciones sin necesidad de hardware o infraestructura. La mayoría del personal utiliza los servicios web en la nube para todo, desde el correo electrónico hasta la colaboración en documentos.
Uso de la web
Estas API web pueden obtenerse desde un proyecto web de usuario, una app de iPhone, un dispositivo IoT o un Windows Mobile, ya que REST no depende de la funcionalidad del lado del cliente. Puede crear la arquitectura para su negocio sin estar limitado a un marco específico del lado del cliente.
Un ejemplo de API REST
Veamos un ejemplo de API REST. Haga clic en el siguiente enlace para solicitar a la base de datos de Open Trivia una consulta de inteligencia arbitraria: Este tipo de servicios web RESTful se utilizó para proporcionar una API web pública. El equipo mostrará una única pregunta de test y sus respuestas en formato JSON.
Utilizando cualquier navegador HTTP, como url, podría emitir la siguiente consulta y recibir una respuesta en el cuerpo de respuesta: https://opentdb.com/api.php?amount=1&category=18
El cuerpo de respuesta del archivo XML del servicio web contendrá toda la información del empleado.
Todos los dialectos de programación y herramientas para desarrolladores ampliamente utilizados tienen bibliotecas de cliente HTTP, como retrieve en JavaScript, Node.js y Deno y file get contents() en PHP. Una respuesta JSON puede ser leída y utilizada ya que es legible por la máquina antes de ser mostrada en HTML u otro estilo.
Las APIs Rest y REST
Con el tiempo, se han desarrollado muchos métodos de transmisión de datos. Es posible que te hayas encontrado con opciones como CORBA, SOAP o XML-RPC. La mayoría desarrollaron estrictas pautas de mensajes. Roy Fielding esbozó por primera vez REST en 2000, que es mucho más sencillo que los demás.
Se trata de una colección de sugerencias y limitaciones para los servicios web RESTful más que de una norma. Consisten en las siguientes limitaciones arquitectónicas:
Partición cliente-servidor
Los clientes y los servidores web sólo pueden comunicarse en una dirección bajo la arquitectura REST: el cliente solicita al controlador de dominio, y el controlador o servidor responde a la solicitud. Los servidores web no pueden enviar solicitudes, y los clientes no pueden reaccionar; el consumidor inicia todas las conexiones.
Los servicios web RESTful mantienen aislados a los clientes y a los servidores facilitando la interacción entre ellos. Los equipos de los clientes pueden desarrollarse sin temor a afectar a otro alojamiento, y los materiales de los servidores pueden cambiarse sin afectar involuntariamente a los clientes.
Interfaz uniforme
Según esta estrategia, todas las consultas y reacciones deben adherirse a un procedimiento proweb estándar o estilizar sus mensajes. Las aplicaciones y los servidores se desarrollan en varios lenguajes de programación que funcionan mal entre sí con un mediador. Una interfaz uniforme es un dialecto que cualquier cliente puede utilizar para interactuar con cualquier API REST.
Sólo sería posible traducir las peticiones y reacciones entre aplicaciones con una interacción normalizada. Las pequeñas diferencias se mezclarían y perderían información, y las soluciones tendrían que actualizar sus procedimientos de solicitud cuando las APIs web modificaran los suyos. Una interfaz coherente elimina esta perspectiva.
ACCESO A https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Como todas las aplicaciones de clientes REST, esta propuesta incluye dos datos. La técnica HTTP es GET. Describe la acción que el cliente desea realizar sobre los recursos. Un usuario puede realizar cuatro métodos HTTP básicos:
HTTP, o Hyper-Text Transfer Protocol, es el lenguaje universal para la mayoría de las APIs REST. HTTP no fue diseñado con REST en mente. Además, REST aceptó esta transmisión de datos como criterio para las aplicaciones compatibles con REST. Para utilizar HTTP con las APIs REST, el cliente envía una petición en un formato que quizá conozcas. Una petición de señal de vídeo a la API de YouTube, por ejemplo, tiene este aspecto:
- Utiliza el comando GET para obtener un recurso.
- Utilice el comando POST para hacer un nuevo recurso
- Utilice la instrucción PUT para realizar cambios o seguir actualizando un recurso existente
- Utilice la instrucción DELETE para deshacerse de un recurso.
Los métodos HTTP especifican la acción que se pretende realizar con respecto a un recurso específico. Los métodos HTTP también se conocen como verbos HTTB.
La URL es HTTP
El identificador uniforme de recursos, o URI, que identifica el recurso previsto está contenido en la URL. La URL es también un punto final en este escenario, ya que es donde la API RESTful entra en contacto con el usuario del servicio.
Cadena de consulta: La URL incluye una cadena de consulta. La cadena de consulta se utiliza para definir los parámetros, a los que se dan valores.
Después de recibir y verificar la petición, el servidor web devuelve los datos sobre el recurso al que se dirige. Normalmente, los datos se devuelven en una estructura conocida como JSON (JavaScript Object Notation). JSON presenta todos los componentes de un recurso en un formato portátil que los humanos pueden leer fácilmente.
Principios de la interfaz uniforme
La interfaz uniforme debe seguir los siguientes parámetros
HATEOAS: Hipermedia como motor del estado de la aplicación
Los hipermedios son el motor de los servicios web RESTful. Esto indica que el hipermedia es todo lo que el cliente quiere comprender para reconocer la respuesta del proveedor.
- Sólo debe proporcionarse al cliente la primera URI de la aplicación. La aplicación cliente debe conducir continuamente todos los demás materiales y actividades mediante hipervínculos.
- Los servicios web RESTful no requieren el lenguaje de consulta de entrada (IDL), que difiere de otras API
Un tipo de medio es un nombre para el formato de datos de una representación. El tipo de medio identifica una definición que describe cómo debe tratarse una representación. Una API web que utiliza REST parece un hipertexto. Cada elemento de datos al que se puede dirigir lleva una ubicación, ya sea directamente (como a través de las propiedades de enlace e identidad) o implícitamente (por ejemplo, derivado de la estructura de descripción del tipo de medio).
Mensajes autodescriptivos
Cada comunicación entre el lado del cliente y el lado del servidor debe proporcionar datos suficientes para ejecutar la comunicación. En consecuencia, la solicitud del lado del cliente al lado del servidor debe especificar el recurso al que intenta acceder junto con sus objetivos específicos.
Además, las representaciones de los recursos deben ser autodescriptivas; el usuario no tiene que saber si un recurso es una persona o un equipo. En su lugar, debe responder siguiendo el tipo de medio conectado a la ayuda.
Por lo tanto, indiscutiblemente, desarrollaremos muchos tipos de medios únicos, a menudo un tipo de medio por recurso. Cada tipo de medio especifica un paradigma de producción estándar. Por ejemplo, HTML define cómo se muestra el hipertexto y cómo el navegador maneja cada componente.Identificación de los recursos
Los recursos a los que se hace referencia en las comunicaciones posteriores entre el cliente y el servidor tienen que ser reconocibles mediante representaciones. El hecho de ceñirse al sistema de Identificadores de Recursos Uniformes (URI) lo permite. En otras palabras, la comunicación del servidor al cliente puede incluir una versión HTML del documento y alguna información en lugar del archivo real del almacenamiento del servidor.
El consumidor puede entender fácilmente la versión HTML porque sigue el patrón URI. El cliente debe modificar los recursos dando al servidor una representación de cómo debería aparecer finalmente el recurso. Esto permitiría al usuario construir, recuperar, modificar y eliminar recursos. Si el cliente tiene la autorización necesaria para modificar los datos, el servidor debe cumplir la consulta.
Start FreeTry AppMaster no-code today!Platform can build any web, mobile or backend application 10x faster and 3x cheaper
Sin estado
Con una API RESTful, todas las solicitudes de los clientes deben ser transitorias. En consecuencia, cada consulta y cuerpo de respuesta incluyen todos los datos necesarios para concluir el contrato, lo que hace que cada conexión sea autónoma. El servidor no lleva la cuenta de las peticiones HTTP anteriores, sino que trata cada una de ellas realizada por el cliente como una consulta completamente nueva.
Dado que el servidor no tiene que realizar ninguna tarea adicional para obtener datos históricos, los transportes sin estado minimizan significativamente la cantidad de almacenamiento necesaria para el servidor y aumentan la probabilidad de que una respuesta sea aceptable. Esto garantiza la escalabilidad de estas interacciones: los programadores no tienen que preocuparse por utilizar mucho más almacenamiento o gravar al servidor cuando su software se amplía y realiza peticiones HTTP.
Capas
Hasta ahora hemos definido las consultas de la API web como un intercambio directo entre cliente y servidor, aunque esto es simplificar un poco. Entre estas dos organizaciones, suele haber más servidores. Estas plataformas, o capas, sirven para gestionar y dispersar el tráfico, añadir protección y realizar otras tareas cruciales.
Según este concepto, los mensajes enviados entre un usuario y un servidor de destino deben estructurarse y tratarse de forma similar, independientemente de las capas que existan en medio. Las capas adicionales deben estar bien con las interacciones de los clientes. Los programadores que se adhieren a esta regla pueden cambiar los sistemas de los servidores sin afectar al proceso fundamental de solicitud-respuesta.
Almacenamiento en caché
El almacenamiento en caché se produce cuando un cliente navega por un sitio web cuando el contenido se guarda en la máquina del cliente. El material almacenado en caché se carga rápidamente desde la memoria interna en lugar de descargarse de nuevo desde el servidor cuando un usuario visita ese sitio más tarde. La mayoría de los grandes sitios utilizan la memoria caché para reducir la carga de las páginas y conservar el espacio del servidor y el ancho de banda.
El almacenamiento en caché de datos se tiene en cuenta cuando se desarrollan APIs REST. La respuesta que un servidor da a un cliente debe indicar si el recurso dado puede almacenarse y durante cuánto tiempo.
Código en demanda
El último principio de REST es innecesario. Si se solicita, la respuesta de una API puede incluir código de software para que los clientes lo utilicen. Por ello, el cliente puede ejecutar la aplicación o el programa del cliente en su backend.
Se considera que una API es RESTful si cumple con este conjunto de directrices. Sin embargo, estas directrices dan a los programadores mucha libertad para modificar las características de su API RESTful. Las APIs REST se diferencian del Protocolo Simple de Acceso a Objetos, otra popular técnica de APIs web, en que son más flexibles (SOAP).
Consenso de puntos finales
Tenga en cuenta estos puntos finales:
- /usuario/123\s
- /usuario/id/123\s
- /user/123\s/user/id/123\s
- /usuario/?id=123
Todos son métodos legítimos para que el cliente 123 recupere datos. Cuando hay procedimientos más complicados, el número de posibilidades crece. Por ejemplo, en orden inverso, empezando por la entrada 51, muestra 10 personas con apellidos que empiezan por "A" y que operan para la empresa.
Al final, no importa cómo estructures las URL; lo que importa es la uniformidad en toda tu API RESTful. En sistemas de software enormes con muchos programadores, eso no puede ser fácil. Las modificaciones de la API RESTful son inevitables, pero las URLs de los puntos finales nunca deben ser rechazadas porque al hacerlo las aplicaciones que dependen de ellas dejarán de funcionar.
Versionado de la API REST
Versionar las API es una práctica habitual para evitar incompatibilidades. Por ejemplo, /2.0/user/123 sustituye a /user/123. Los puntos finales antiguos y nuevos pueden seguir funcionando. En consecuencia, esto obliga a mantener las APIs importantes del pasado. Las versiones anteriores pueden retirarse en última instancia, pero el procedimiento debe ser cuidadosamente pensado.
Autenticación de la API REST
Cualquier dispositivo puede descargar un quip sin autorización utilizando la API de consulta. Las API que leen información privada o que permiten editar y eliminar consultas no lo admiten. Los programas del lado del cliente que se encuentran en el mismo dominio que los servicios web RESTful envían y reciben cookies del mismo modo que las solicitudes HTTP. (Tenga en cuenta que la opción de reinicio de privilegios debe especificarse en sitios anteriores para Fetch()). Se puede verificar una consulta a la API para confirmar que un usuario ha iniciado sesión y tiene los permisos necesarios.
Autenticación básica HTTP: Los programas de terceros deben utilizar diferentes soluciones de aprobación. Algunos métodos populares de autenticación son la verificación primaria para:
- HTTP. Se proporciona una cadena de nombre de usuario: contraseña codificada en base64 en el campo de consulta como parte de una cabecera de aprobación HTTP.
- Claves de la API: Al proporcionar una clave de API RESTful que puede tener permisos especiales o estar limitada a un solo sitio, una API se pone a disposición de las aplicaciones de terceros. Cada mensaje contiene la clave en la cadena de consulta o en la cabecera HTTP. (La cadena de consulta es un componente de la URL).
- OAuth: Antes de realizar cualquier solicitud, se envía un ID de cliente y quizás un secreto de cliente a un servidor OAuth para obtener una credencial. Hasta su caducidad, la identidad OAuth se transmite entonces junto con cada solicitud de API.
- Tokens de Internet en JSON (JWT): La cabecera de consulta y la cabecera de respuesta transmiten de forma segura las credenciales de usuario firmadas digitalmente. Los JWT permiten al servidor cifrar los privilegios de acceso, eliminando la necesidad de consultar una base de datos o de utilizar otro mecanismo de autenticación.
El escenario de uso afectará a cómo se autentifica una API:
- A veces, un programa de terceros se maneja como cualquier otro cliente conectado con los mismos privilegios y derechos. Por ejemplo, una API de mapas puede proporcionar a un programa solicitante instrucciones entre dos puntos. Debe verificar que el programa es un usuario legítimo, pero no tiene que verificar las credenciales del cliente.
- En otras situaciones, el programa de terceros solicita información personal de un usuario concreto, como el contenido del correo. Las API de REST deben reconocer al cliente y sus permisos, pero no tienen que preocuparse por el programa que llama.
Seguridad de las APIs REST
Los servicios web RESTful añaden una forma más de interactuar con su software e influir en él. Incluso si su host no es un objetivo elevado de hacking, un usuario que se comporte mal podría enviar cientos de peticiones por segundo y colapsarlo. Este artículo no cubre la seguridad, pero implica los mejores procedimientos estándar:
Hacer uso de HTTPS
Emplear un mecanismo de autenticación fuerte
Utilizar CORS para restringir las llamadas de los clientes a determinadas áreas.
Proporcionar las necesidades de capacidades - es decir, no
Generar opciones DELETE que no sean necesarias; verificar todas las URLs de los extremos y la información del cuerpo.
Bloquear los enlaces de sectores o direcciones IP no identificados, no sometiendo los vales de la API en el JavaScript del lado del cliente.
Se bloquean los paquetes anormalmente grandes.
Piense en la restricción de la tasa, donde las solicitudes de la misma dirección IP o credencial de la API están restringidas a N consultas por minuto.
Respuesta con el código de estado HTTP adecuado, consultas de registro de cabecera de caché e investigación infructuosa
Múltiples solicitudes y datos innecesarios
El despliegue de servicios web RESTful tiene limitaciones. Es posible que una respuesta tenga más información de la solicitada o que se requieran múltiples peticiones para obtener toda la información. Piensa en los servicios web RESTful que dan acceso a los usuarios a la información del creador y del libro; el cliente podría
- Pedir la información de los 10 primeros libros, listados por orden de compra (el más vendido primero). En la respuesta se incluye una colección de libros, junto con el ID de cada escritor.
Para recuperar la información de cada escritor, construya hasta 10 consultas /author/id.
Deben generarse N consultas API por cada respuesta a la consulta principal, lo que se caracteriza como el "problema N+1".
Si se trata de una situación de uso frecuente, los servicios web RESTful podrían modificarse para incluir toda la información del escritor para cada libro que produzca, incluyendo el nombre, género, nacionalidad, biografía, etc. Se puede proporcionar incluso más información sobre sus libros anteriores, aunque hacerlo aumentaría considerablemente la carga de respuesta. La API puede modificarse para que la información del escritor sea opcional. Author details=full para evitar respuestas innecesariamente grandes. El gran número de opciones que deben soportar los diseñadores de la API podría ser abrumador.
Para terminar
Ahora ya entiendes a fondo las APIs de REST, cómo funcionan las APIs de REST, ejemplos de APIs de REST, para qué se usan las APIs de REST, restricciones arquitectónicas y otros temas cubiertos en este tutorial. Los programadores pueden encontrar difícil e intimidante el aprendizaje de las APIs, pero la plataforma sin código AppMaster ha creado una nueva biblioteca accesible de APIs REST en la que podrá profundizar en el conocimiento de una serie de APIs REST para apoyar su posterior desarrollo profesional.
En AppMaster, intentamos aumentar la accesibilidad y usabilidad de las API. Queremos que conozcas, experimentes y te des cuenta de las ventajas de utilizar las API en tu carrera y en tu vida personal. Para ayudarle a diseñar mejores APIs web más rápidamente, AppMaster mejora la colaboración y automatiza cada etapa del ciclo de vida de las APIs. Siga creando, avanzando y ampliando su comprensión de las APIs REST.
