REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples
1.0.0
REST es acrónimo de transferencia de estado de representación . Restful API es un estilo arquitectónico para una interfaz del programa de aplicación (API) que utiliza solicitudes HTTP para acceder y alterar datos. Esos datos se pueden usar para obtener, poner, publicar y eliminar los tipos de datos, que se refieren a la lectura, actualización, creación y eliminación de operaciones sobre recursos. Para más detalles
Las funciones principales utilizadas en cualquier arquitectura basada en REST son:
Su solicitud debe satisfacer ciertas restricciones o principios. Vamos a detalles sobre estos principios.
Hay seis principios de tierra, a continuación se encuentran los seis principios rectores de descanso:
Sin estado: las solicitudes enviadas de un cliente al servidor contienen toda la información necesaria que se requiere para comprenderla completamente. Puede ser parte de los parámetros URI, de la cuerda de consultas, el cuerpo o incluso los encabezados. El URI se usa para identificar de manera única el recurso y el cuerpo posee el estado del recurso solicitante. Una vez que el servidor realiza el procesamiento, se devuelve una respuesta apropiada al cliente a través de encabezados, estado o cuerpo de respuesta.
Servidor cliente: tiene una interfaz uniforme que separa a los clientes de los servidores. La separación de las preocupaciones ayuda a mejorar la portabilidad de la interfaz de usuario en múltiples plataformas, así como mejorar la escalabilidad de los componentes del servidor.
Interfaz uniforme: para obtener la uniformidad en toda la aplicación, REST ha definido cuatro restricciones de interfaz que son:
Resource identification
Resource Manipulation using representations
Self-descriptive messages
Hypermedia as the engine of application state
Almacenable: para proporcionar un mejor rendimiento, las aplicaciones a menudo se hacen almacenarse en caché. Se realiza etiquetando la respuesta desde el servidor como almacenamiento en caché o no consecuente, ya sea implícita o explícitamente. Si la respuesta se define como almacenado en caché, entonces el caché del cliente puede reutilizar los datos de respuesta para respuestas equivalentes en el futuro. También ayuda a prevenir la reutilización de los datos obsoletos.
Sistema en capas: la arquitectura del sistema en capas permite que una aplicación sea más estable al limitar el comportamiento de los componentes. Esta arquitectura permite el equilibrio de carga y proporciona cachés compartidos para promover la escalabilidad. La arquitectura en capas también ayuda a mejorar la seguridad de la aplicación, ya que los componentes en cada capa no pueden interactuar más allá de la siguiente capa inmediata en la que se encuentran.
Código a pedido: el código a pedido es una restricción opcional y se usa menos. Permite que el código de los clientes o los applets se descargue y se extienda a través de la interfaz que se utilizará dentro de la aplicación. En esencia, simplifica a los clientes creando una aplicación inteligente que no depende de su propia estructura de código.
Ahora que sabe qué es una API REST y lo que necesita importar para ofrecer una aplicación eficiente, sumergamos más y veamos el proceso de construcción de API REST utilizando todas las tecnologías de tendencia y marco.
REST y el protocolo de acceso de objetos simple (SOAP) Ofrece 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 de descanso pueden usar SOAP.
Los servicios web RESTFUL son estatales. 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 está transmitiendo, ya que no existe un conjunto estándar de reglas para describir la interfaz REST Web Services. Los servicios de descanso son útiles para dispositivos de perfil restringido, como el móvil, y son fáciles de integrar con los sitios web existentes.
SOAP requiere menos código de plomería que significa código de infraestructura de bajo nivel que conecta los módulos del código principal 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 y la invocación asincrónicos.
Estos son algunos puntos que debe considerar al desarrollar API REST:
Las cargas útiles extremadamente grandes de los datos de respuesta ralentizarán la finalización de la solicitud, otras llamadas de servicio y, en el efecto, degrade el rendimiento. Como saben, ahora que estamos devolviendo todos los pedidos para el cliente en lugar de solo su pedido actual, tendremos que lidiar con cierta degredación del rendimiento.
Podemos usar GZip Compression para reducir nuestro tamaño de carga útil. Esto disminuye el tamaño de descarga de nuestra respuesta en la aplicación web (lado del cliente), así como aumenta la velocidad de carga o la creación de alguna entidad (pedidos). Podemos usar Deflate compression en una API web. O bien, podemos actualizar el encabezado Acept-EngodingRequest a GZIP .
El almacenamiento en caché es uno de los métodos más fáciles para mejorar el rendimiento de una API. Si tenemos solicitudes que con frecuencia devuelven la misma respuesta, entonces una versión en caché de esa respuesta ayuda a evitar llamadas de servicio adicionales/consultas de base de datos . Querrá asegurarse de que se use en caché para invalidar periódicamente los datos en el caché, especialmente cuando ocurren nuevas actualizaciones de datos.
Supongamos que nuestro cliente quiere hacer un pedido para una parte automática, y nuestra aplicación llama a algunas API de autopartes para obtener el precio de la pieza. Dado que la respuesta (precio de pieza) solo cambia una vez a la semana (a la 1:00 a.m.), podemos almacenar en caché la respuesta por el resto del tiempo hasta entonces. Esto nos ahorra hacer una nueva llamada cada vez para devolver el mismo precio de pieza. Caso similar puede usar caché para evitar llamadas o solicitudes adicionales.
Una red lenta degradará el rendimiento de incluso la API más robusta. Las redes poco confiables pueden causar tiempo de inactividad, lo que podría hacer que su organización viole las SLA, los términos de servicio y las promesas que puede haber hecho a sus clientes. Es importante invertir en la infraestructura de red adecuada, para que podamos mantener el nivel de rendimiento deseado. Esto se puede lograr aprovechando y comprando suficientes recursos e infraestructura en la nube (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) . Además, si tiene una gran cantidad de procesos de fondo, ejecutelos en hilos separados para evitar solicitudes de bloqueo. También puede usar espejos y redes de entrega de contenido (CDN) como CloudFront para atender solicitudes más rápido en diferentes partes del mundo.
Puede tener una situación en la que su API sufra un ataque DDoS que puede ser malicioso e intencional, o no intencional cuando un ingeniero llama a la API para ejecutar un bucle de alguna aplicación local. Puede evitar esto midiendo las transacciones y monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API) .
Este método para limitar la velocidad ayuda a reducir las solicitudes excesivas que retrasarían la API, ayuda a lidiar con llamadas/ejecuciones accidentales, y monitorear e identificar de manera proactiva la posible actividad maliciosa.
Es una idea errónea común entre los ingenieros que colocan y las operaciones de parche producen el mismo resultado. Son similares en la actualización de los recursos, pero cada uno realiza las actualizaciones de manera diferente. Ponga los recursos de actualización de operaciones enviando actualizaciones a todo el recurso. Las operaciones de parche aplican actualizaciones parciales solo a los recursos que necesitan actualización. Las llamadas de intoperación resultantes que producen cargas útiles más pequeñas y mejoran el rendimiento a escala.
Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent.
Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls.
So, you should carefully and deliberately consider your application for using PATCH requests,
and make sure that they are idempotently implemented if needed. If not, use PUT requests.
Este es quizás uno de los consejos más importantes que leerá aquí. Si hay una cosa que debes aprender de este repositorio, ¡debería ser esto! No hay negociación sobre este.
Tener registros, monitorear y alertar ayuda a los ingenieros a diagnosticar y remediar problemas antes de que se conviertan en problemas . Muchas API (Express/Node, Java, GO) tienen puntos finales predefinidos para evaluar cosas como:
`/health`
`/metrics`
Si no tiene habilitado el registro, y existe un problema potencial, no podrá rastrear el origen o dónde se produce el problema en una solicitud en particular.
Si no tiene habilitado el monitoreo, no sabrá desde una perspectiva analítica con qué frecuencia se producen algunos problemas o errores. Que luego le impedirá pensar en posibles soluciones.
Y ... si no tiene alertas habilitadas, no sabrá si hay un problema, hasta que un cliente (o peor, los clientes) lo denuncien.
La paginación ayuda a crear cubos de contenido a partir de múltiples respuestas . Este tipo de optimización ayuda a mejorar las respuestas al tiempo que preserva los datos que se transfieren/se muestran a un cliente. Puede estandarizar, segmentar y limitar las respuestas que ayudan a reducir la complejidad de los resultados y mejorar la experiencia general del cliente al proporcionar la respuesta/resultados solo para lo que un cliente ha solicitado.
Sabemos que las API son increíbles y pueden ser extremadamente poderosas para proporcionar a los negocios y a los clientes una gran experiencia, si se optimizan y mejoran adecuadamente para el rendimiento. Los requisitos comerciales y las expectativas del cliente siempre evolucionan con el tiempo. Y como ingenieros responsables, depende de nosotros decidir cómo construir nuestras API de manera rentable, lo que puede ayudarnos a lograr y superar nuestros objetivos.
Estos consejos son solo la punta del iceberg, y se aplican a todas las API en un entorno general. Dependiendo de su API y caso de uso en particular, con qué servicios interactúan, con qué frecuencia se llama, desde donde se llama, etc. Es posible que tenga que implementar estos consejos de diferentes maneras.
API REST con Laravel - Pasaporte
API REST con PHP - OOPS
API REST con Python - Flask
REST API con Python - Django - Restframework
REST API con Go - Mux
REST API con Go - Gin
API REST con NodeJS - Express - Básico
API REST con NodeJS - Express- JWT - Sequellze - Avance
Muy fácil de crear API REST en un par de minutos, puede elegir cualquiera de la base de código anterior de acuerdo con las preferencias de su idioma y marco y seguir instrucciones para crear API REST.
Feliz codificación?
LinkedIn: https://www.linkedin.com/in/the-startup-cto/
Medio: https://apige.medium.com/
Twitter: https://twitter.com/htngapi
