En la industria , las integraciones juegan un papel clave en el diseño de aplicaciones. Una de las principales tecnologías para esto es la . El conocimiento de la API REST es una habilidad importante para todo especialista en tecnología. En este artículo, presentaremos 25 preguntas de la API REST que lo ayudarán a prepararse para una entrevista de trabajo y mejorar sus habilidades. ¡Disfruta leyendo! del desarrollo de software API REST En primer lugar, el entrevistador suele dividir las preguntas sobre API REST en teóricas y prácticas. Primero, le harán 2 o 3 preguntas teóricas sobre terminología y métodos de solicitud HTTP, y luego recibirá una tarea práctica sobre cómo redactar una solicitud. Este artículo contiene preguntas teóricas frecuentes y planeo publicar ejemplos de tareas prácticas relacionadas con la API REST en el próximo artículo. No sabemos de antemano qué preguntas recibirá en una entrevista, pero estoy seguro de que en el proceso de trabajar con nuestra lista de preguntas típicas, probablemente profundizará en el tema y mejorará su conocimiento de la API REST en cualquier caso. Ahora, pasemos de lo simple a lo complejo, comenzando con la terminología básica y continuando con una sección con preguntas más complejas. 1. ¿Qué es el DESCANSO? Respuesta: Hay tres términos utilizados cuando se hace referencia a REST que a menudo se consideran lo mismo, pero esto no es del todo cierto. Estos términos son REST, REST API y RESTful API. Ahora habrá una respuesta sobre REST, el término significa Representational State Transfer y es un estilo arquitectónico basado en el protocolo HTTP (Hypertext Transfer Protocol) para desarrollar aplicaciones que tengan un front-end y/o integración con sistemas externos. REST describe las pautas que deben seguir los servicios API que se diseñan. Estos principios garantizan que las solicitudes se transmitan entre el cliente y el servidor mediante HTTP. 2. ¿Qué es la API REST? Respuesta: Una API es una interfaz de programación que permite que aplicaciones individuales se comuniquen e intercambien datos. Por ejemplo, una aplicación de entrega de alimentos puede utilizar la API de Google Maps para rastrear la ubicación del mensajero y mostrarla en un mapa. Una API REST es una API que sigue los principios de REST y trata todos los datos como recursos, cada uno representado por un identificador uniforme de recursos (URI) único. 3. ¿Qué es una API RESTful? Respuesta: Una API RESTful es una API diseñada según las reglas (o también puedes decir “principios”) de REST. En otras palabras, la diferencia entre REST API y RESTful API es terminológica. El primer caso se refiere a un conjunto de reglas REST, y el segundo se refiere a la implementación de una API específica siguiendo reglas REST. El término API RESTful a menudo se reemplaza por API REST o incluso REST simplemente por razones de brevedad. Cuando los analistas de sistemas dibujan flechas etiquetadas como REST en un diagrama de aplicación, se refieren a una API RESTful. 4. ¿Cuáles son los dos principios fundamentales de REST? Respuesta: Las solicitudes de API REST deben seguir dos principios básicos: Separación en cliente y servidor: La interacción entre el cliente y el servidor se realiza en forma de solicitudes y respuestas. Sólo los clientes pueden realizar solicitudes y sólo los servidores pueden enviar respuestas para funcionar de forma independiente unos de otros. Protocolo único: La interacción entre el cliente y el servidor debe realizarse mediante un protocolo único. Para REST, este protocolo es HTTP. 5. ¿Qué otros principios de REST conoces? Respuesta: Puedes nombrar al menos 4 principios más. Las solicitudes de API REST no almacenan el estado en el servidor y pueden pasar a través de capas de servidores y almacenarse en caché. También puede enviar código ejecutable a los clientes en la respuesta del servidor. Servidor sin estado: el servidor no almacena ninguna información sobre solicitudes/respuestas pasadas. Cada solicitud y respuesta contiene toda la información necesaria para completar la interacción. La comunicación sin estado reduce la carga del servidor, ahorra memoria y mejora el rendimiento. Sistema por capas: son posibles servidores adicionales entre el cliente y el servidor API en forma de capas para realizar diferentes funciones. En un sistema construido sobre principios REST, las capas son modulares y se pueden agregar y eliminar sin afectar las comunicaciones entre el cliente y el servidor. Capacidad de almacenamiento en caché: las respuestas del servidor indican si su recurso se puede almacenar en caché para que los clientes puedan almacenar en caché cualquier recurso para mejorar el rendimiento. Código bajo demanda: el servidor puede enviar código ejecutable a los clientes en su respuesta para su ejecución dentro de la aplicación del cliente. 6. ¿Qué es un recurso? Respuesta: En REST, cada objeto accesible en el lado del servidor se designa como recurso. Un recurso es un objeto que tiene un tipo, datos asociados, una relación con otros recursos en el servidor y una lista de métodos que se pueden usar para trabajar con él. Por ejemplo, un recurso podría ser un archivo HTML o de texto, un archivo de datos, una imagen o vídeo, o un archivo de código ejecutable. Un recurso se identifica mediante un identificador uniforme de recursos o URI. Los clientes acceden a los recursos utilizando sus URI en solicitudes HTTP. 7. ¿Qué es una URL? Respuesta: URI significa Identificador uniforme de recursos. Esta es una cadena que identifica un recurso en el servidor. Cada recurso tiene su propio URI único que, cuando se incluye en una solicitud HTTP, permite a los clientes acceder y realizar acciones en ese recurso. El proceso de hacer referencia a un recurso mediante su URI se denomina "direccionamiento". 8. ¿Qué es CRUD? Respuesta: CRUD significa "Crear, Leer, Actualizar, Eliminar". Estas son las cuatro acciones principales que se pueden realizar en bases de datos a través de la API REST. Cada acción tiene su propio método de solicitud HTTP: Crear = PUBLICAR Leer = OBTENER Actualizar = PONER Eliminar = BORRAR 9. ¿Qué se entiende por carga útil en la respuesta del servidor? Respuesta: La carga útil de respuesta HTTP se refiere a los datos de recursos solicitados por el cliente. Esto también se denomina brevemente "carga útil de respuesta HTTP". Estos datos pueden estar en JSON, XML, HTML, imágenes, archivos, etc., dependiendo de lo que proporcione exactamente el servidor. 10. ¿Qué es la mensajería REST? Respuesta: La mensajería en REST se refiere al intercambio de mensajes entre el cliente y el servidor. La comunicación siempre comienza cuando el cliente realiza una solicitud HTTP al servidor. El servidor procesa esta solicitud y luego envía una respuesta HTTP que indica el estado de la solicitud y los recursos que solicitó el cliente. 11. ¿Qué es un intermediario de mensajes en REST? Respuesta: En el contexto de REST, el término "agente de mensajes" es un middleware que sirve para pasar mensajes entre varios componentes o sistemas en una aplicación distribuida. El intermediario puede proporcionar intercambio de datos asincrónico, colas de mensajes y procesamiento de mensajes entre varios módulos del sistema. Los intermediarios de mensajes se pueden utilizar para gestionar operaciones asincrónicas o enviar notificaciones. El intermediario de mensajes no es un elemento REST nativo porque... REST se centra en la comunicación sincrónica entre el cliente y el servidor mediante solicitudes HTTP. 12. ¿Qué métodos de solicitud HTTP admite REST? Respuesta: El método de solicitud HTTP especifica la acción deseada que realizará el servidor en el recurso. En REST, existen cuatro métodos principales para realizar solicitudes HTTP desde un cliente a un servidor: GET: Solicita un recurso del servidor, este método es de solo lectura. POST: Crea un nuevo recurso en el servidor. PUT: Actualiza un recurso existente en el servidor. DELETE: Elimina un recurso del servidor. 13. ¿Cuál es la diferencia entre los métodos POST y PUT? Respuesta: POST sirve para crear un recurso en el servidor, mientras que PUT sirve para reemplazar un recurso en un URI específico por otro recurso. Si usa PUT en un URI que ya tiene un recurso asociado, PUT lo reemplazará. Si no hay ningún recurso en el URI especificado, PUT crea uno. PUT es idempotente, lo que significa que llamarlo varias veces dará como resultado la creación de un solo recurso. Esto sucede porque cada llamada reemplaza un recurso existente (o crea uno nuevo si no hay nada que reemplazar). POST no es idempotente. Si, por ejemplo, llama a POST 10 veces, se crearán 10 recursos diferentes en el servidor, cada uno con su propio URI. Aunque rara vez se utilizan, las respuestas POST se pueden almacenar en caché, pero las respuestas PUT no. Las solicitudes POST generalmente se consideran no almacenables en caché, pero se pueden almacenar en caché cuando contienen información clara sobre la "actualidad" de los datos. Una respuesta más detallada es que la respuesta para una solicitud POST (o PATCH) se puede almacenar en caché si los datos están "nuevos" y el encabezado Content-Location (en-US) está configurado, pero esto rara vez se implementa. Por lo tanto, si es posible, se debe evitar el almacenamiento en caché de POST. 14. ¿Cuáles son las partes principales de una solicitud HTTP? Respuesta: En REST, existen los siguientes componentes básicos de una solicitud HTTP: El método de solicitud que se realizará al recurso (es decir, GET, POST, PUT, DELETE). Un URI que identifica el recurso solicitado en el servidor. Versión HTTP: es decir, qué versión debería estar en la respuesta del servidor. El encabezado de la solicitud HTTP contiene metadatos sobre la solicitud, como el agente de usuario, formatos de archivo aceptados por el cliente, formato del cuerpo de la solicitud, idioma, preferencias de almacenamiento en caché, etc. El cuerpo de una solicitud HTTP, contiene todos los datos asociados con la solicitud. . Esto sólo es necesario si la solicitud es cambiar datos en el servidor utilizando los métodos POST o PUT. 15. ¿Cuáles son las partes principales de una respuesta HTTP? Respuesta: Las respuestas HTTP se envían desde el servidor al cliente. Informan al cliente que la acción solicitada se ha completado (o no) y la entrega de los recursos solicitados. Hay cuatro componentes principales de una respuesta HTTP: Versión HTTP utilizada. Barra de estado con estado de solicitud y código de estado de respuesta HTTP. Encabezado de respuesta HTTP con metadatos sobre la respuesta, incluida la hora, el nombre del servidor, el agente de usuario, los formatos de archivos de recursos devueltos y la información de almacenamiento en caché. Cuerpo de respuesta HTTP que contiene datos sobre el recurso solicitado por el cliente 16. Nombra al menos 3 códigos para respuestas exitosas del servidor HTTP Respuesta: El servidor devuelve los siguientes códigos de estado de operación cuando la solicitud se procesa correctamente: 200 OK: La solicitud se completó con éxito. 201 Creado: la solicitud fue exitosa y se creó el recurso. 202 Aceptado: este estado significa que el servidor aceptó la solicitud del cliente pero no completó su procesamiento. El procesamiento puede ser asincrónico. 17. Nombra al menos 4 códigos de respuesta HTTP del servidor al redirigir una solicitud. Respuesta: El servidor devuelve los siguientes códigos de estado al redirigir una solicitud: 301 Movido permanentemente: este estado le dice al cliente que el recurso solicitado se ha movido permanentemente a otra URL y el cliente debe acceder a la nueva URL para acceder al recurso. 302 Encontrado: este estado indica que el recurso se ha movido temporalmente a otra URL y el cliente debe usar temporalmente la nueva URL. Redirección temporal 307: similar a 302, pero el cliente debe utilizar el mismo método de solicitud al acceder a la nueva URL. Redireccionamiento permanente 308: similar al 301, pero el cliente debe usar el mismo método de solicitud al acceder a la nueva URL 18. Nombra al menos 4 códigos para respuestas fallidas del servidor HTTP. Respuesta: El servidor devuelve los siguientes códigos cuando la solicitud no tiene éxito: 400 Solicitud incorrecta: la solicitud no se completó debido a un error en la solicitud, como un error tipográfico o datos faltantes. 401 No autorizado: la solicitud no se completó porque el cliente no está autenticado o no tiene permiso para acceder al recurso solicitado. 403 Prohibido: la solicitud no se completó porque el cliente está autenticado pero no autorizado para acceder al recurso solicitado. 404 No encontrado: la solicitud no se completó porque el servidor no pudo encontrar el recurso solicitado. 19. Nombra al menos 3 códigos de error del servidor. Respuesta: El servidor devuelve los siguientes códigos cuando hay un error en el servidor: 500 Error interno del servidor: la solicitud no se completó debido a un problema inesperado con el servidor. 502 Puerta de enlace incorrecta: la solicitud no se completó debido a una respuesta incorrecta del servidor ascendente. 503 Servicio no disponible: el servidor no pudo procesar la solicitud debido a mantenimiento, sobrecarga u otras perturbaciones temporales. Puede encontrar una lista de los códigos HTTP más comunes aquí 20. ¿Cuál es la diferencia entre REST y GraphQL? Responder: GraphQL es un lenguaje de consulta que permite a los clientes consultar solo los datos que necesitan. En GraphQL, el cliente define la estructura y formato de los datos que quiere recibir, y el servidor los devuelve según esa solicitud. La diferencia clave es que REST tiene un formato fijo de solicitud y respuesta para cada recurso, mientras que GraphQL permite a los clientes definir su solicitud y obtener solo la información que necesitan, lo que lo hace más eficiente y flexible de usar. 21. ¿Cuál es la diferencia entre REST y SOAP? Respuesta: REST y SOAP (Protocolo simple de acceso a objetos) son dos enfoques para crear API. Hay 3 diferencias principales entre ellos: SOAP es un protocolo estricto para crear API seguras. REST no es un protocolo, sino un estilo arquitectónico dictado por un conjunto de pautas llamadas principios REST. - Las API REST son más sencillas de crear, más ligeras y, en general, más rápidas que las API SOAP. Las API SOAP se consideran más seguras que las API REST, aunque las API REST aún pueden implementar características de seguridad para hacerlas bastante seguras. - REST permite almacenar en caché las respuestas, mientras que SOAP no. SOAP codifica datos en formato XML. - REST permite codificar datos en cualquier formato, aunque XML y JSON son los más populares. 22. ¿Cuál es la diferencia entre REST y AJAX? Responder: JavaScript asíncrono o AJAX es un conjunto de tecnologías de desarrollo web utilizadas en aplicaciones web. Básicamente, AJAX permite que una página web realice solicitudes al servidor y actualice la interfaz de la página sin tener que actualizar toda la página. Un cliente AJAX puede utilizar la API REST en sus solicitudes, pero AJAX no tiene por qué funcionar únicamente con la API REST. Las API REST pueden comunicarse con cualquier cliente, ya sea que use AJAX o no. A diferencia de REST, que utiliza solicitudes y respuestas HTTP para intercambiar mensajes, AJAX envía sus solicitudes al servidor utilizando el objeto XMLHttpRequest integrado en JavaScript. Las respuestas del servidor se ejecutan mediante el código JavaScript de la página para cambiar su contenido. 23. ¿Cuál es el enfoque de "Contrato primero" para el desarrollo de API REST? Respuesta: El enfoque Contract First para el desarrollo de API REST es una metodología en la que la especificación y el contrato de API se crean y definen antes de que comience el desarrollo real. Este contrato sirve como un documento importante que define cómo los clientes pueden interactuar con la API y qué resultados esperados se obtendrán de varias solicitudes. 24. ¿Cuáles son los beneficios de Contract First? Respuesta: Se pueden mencionar las siguientes ventajas del enfoque Contract First: Definición clara de API: la especificación y el contrato de API definen cómo la API debe interactuar con los clientes. Reducir los riesgos: la aprobación preliminar del contrato con los clientes ayuda a reducir el riesgo de malentendidos y de no cumplir con las expectativas de desarrollo de API. Documentación mejorada: el texto del contrato a menudo sirve como documentación para la API, lo que facilita su uso e integración. 25. ¿Cuál es el enfoque Code First para el desarrollo de API REST? Respuesta: El enfoque Code First para el desarrollo de API REST es una metodología en la que primero se desarrolla la funcionalidad API y luego se genera automáticamente una especificación API basada en esa funcionalidad. El sello distintivo del enfoque Code First es que los desarrolladores se centran en escribir la lógica de la API y utilizan herramientas que les permiten crear automáticamente documentación y especificaciones basadas en esa lógica. En general, ambos enfoques, Code First y Contract First, se pueden combinar dentro de un mismo proyecto de desarrollo de API. En este caso, se utiliza Code First para la creación rápida de prototipos, seguido de Contract First para formalizar el contrato. Espero que este artículo le resulte útil a la hora de prepararse para una entrevista de trabajo o de actualizar sus conocimientos sobre la API REST.
