Spring Boot: introducción a los servicios web RESTful

REST significa Transferencia de estado representacional. Fue desarrollado por Roy Thomas Fielding, uno de los principales autores del protocolo web HTTP. En consecuencia, REST fue un enfoque arquitectónico diseñado para hacer un uso óptimo del protocolo HTTP. Utiliza los conceptos y verbos ya presentes en HTTP para desarrollar servicios web. Esto hizo que REST fuera increíblemente fácil de usar y consumir, tanto que es el estándar de referencia para crear servicios web en la actualidad. A diferencia de SOAP, REST no tiene un formato de mensajería estándar. Podemos construir servicios web REST utilizando muchos formatos, incluidos XML y JSON, aunque JSON es la opción más popular. Una cosa importante a considerar es que REST no es un estándar sino un estilo cuyo propósito es restringir nuestra arquitectura a una arquitectura cliente-servidor y está diseñado para usar protocolos de comunicación sin estado como HTTP.

OBTENER

El método de solicitud predeterminado para HTTP. No tenemos ningún cuerpo de solicitud con este método, pero podemos definir múltiples parámetros de solicitud o variables de ruta en la URL. Este método se utiliza para obtener algunos recursos. Dependiendo de la presencia de un parámetro de ID, podemos buscar un recurso específico o buscar una colección de recursos en ausencia del parámetro. Ejemplo de solicitud GET en Spring Boot Controller:

@GetMapping("/user/{userId}")
public ResponseEntity<Object> getUser(@PathVariable int userId) {
    UserEntity user = userService.getUser(userId);
    return new ResponseEntity<>(user, HttpStatus.OK);
}

CORREO

El método POST de HTTP se utiliza para crear un recurso. Tenemos un cuerpo de solicitud en este método y también podemos definir múltiples parámetros de solicitud o variables de ruta en la URL. Ejemplo de solicitud POST en Spring Boot Controller:

@PostMapping(value = "/user")
public ResponseEntity<Object> addUser(@RequestBody UserEntity user) {
    userService.saveOrUpdate(user);
    return new ResponseEntity<>("User is created successfully", HttpStatus.CREATED);
}

PONER

El método PUT de HTTP se utiliza para actualizar un recurso existente. Tenemos un cuerpo de solicitud en este método y también podemos definir múltiples parámetros de solicitud o variables de ruta en la URL. Ejemplo de solicitud PUT en Spring Boot Controller:

@PutMapping("/user/{userId}")
public ResponseEntity<Object> getUser(@RequestBody UserEntity user) {
    userService.saveOrUpdate(user);
    return new ResponseEntity<>("User is updated successfully", HttpStatus.OK);
}

ELIMINAR

El método DELETE de HTTP se utiliza para eliminar un recurso. No tenemos un cuerpo de solicitud en este método, pero podemos definir múltiples parámetros de solicitud o variables de ruta en la URL. Podemos eliminar registros múltiples o únicos, generalmente en función de si tenemos un parámetro de ID o no. Podemos eliminar registros múltiples o únicos, generalmente en función de si tenemos un parámetro de ID o no. Ejemplo de solicitud DELETE en Spring Boot Controller:

@DeleteMapping(value = "/user")
public ResponseEntity<Object> addUser(@PathVariable int userId) {
    userService.deleteUser(userId);
    return new ResponseEntity<>("User is deleted successfully", HttpStatus.OK);
}

Los servicios web REST utilizan la parte de la línea de estado de un mensaje de respuesta HTTP para informar a los clientes sobre el resultado final de su solicitud. Los códigos de estado definidos en HTTP son los siguientes:

• 200 : Éxito
• 201 : Creado
• 401 : no autorizado
• 404 : recurso no encontrado
• 500 : error del servidor

¿Cuándo usar REST?

Los servicios web son completamente apátridas. El productor y el consumidor del servicio tienen un entendimiento mutuo del contexto y el contenido que se transmite. Cuando ya hay alguna infraestructura de captura presente, ya que podemos usarla para mejorar el rendimiento en una API REST. Esto es así porque las requests idempotentes como GET, PUT y DELETE se pueden almacenar en caché. A menudo, el ancho de banda tiene una importancia significativa para las organizaciones. El descanso es fundamental, ya que no hay encabezados generales de la carga útil XML de SOAP. La entrega o agregación de servicios web en sitios web existentes se puede habilitar fácilmente con un estilo RESTful. Simplemente no es necesario revisar la arquitectura, ya que podemos exponer la API como un XML y consumir las páginas web HTML, manteniendo así el contrato externo del servicio.

Principios de los servicios web RESTful

Los siguientes son los principios principales que siguen los servicios de descanso, lo que los hace rápidos, livianos y seguros:

• Identificación de recursos a través de URI: un servicio web RESTful proporciona un URI/ID global independiente para cada recurso.
• Interfaz uniforme: los recursos se manipulan mediante un conjunto fijo de cuatro operaciones de creación, lectura, actualización y eliminación: PUT, GET, POST y DELETE.
• Mensajes autodescriptivos: los recursos y las representaciones se desacoplan en un servicio web RESTful. Esto nos permite representar la carga útil en varios formatos, como HTML, XML, texto sin formato, PDF, JPEG, JSON y otros, según nuestro caso de uso.
• Interacción con estado a través de hipervínculos: cada interacción con un recurso no tiene estado; es decir, los mensajes de solicitud son autónomos.

Ventajas de los servicios web RESTful

Algunas de las principales ventajas de usar servicios web RESTful son

• Fácil de construir: las API REST son más sencillas de construir que una API SOAP correspondiente. Por lo tanto, REST es la mejor opción si queremos desarrollar API rápidamente.
• Independiente: dado que el cliente y el servidor están desacoplados en los servicios web RESTful, permite el desarrollo independiente en todos los proyectos.
• Escalabilidad: la comunicación sin estado y un repositorio replicado proporcionan un alto nivel de escalabilidad. En comparación con SOAP, ampliar un sitio web existente es más fácil con los servicios web REST.
• Sistema en capas: los servicios web REST tienen su aplicación dividida en varias capas que forman una jerarquía. Hace que la aplicación sea tanto modular como escalable.