REST significa Transferencia de Estado REpresentacional.

REST es una arquitectura basada en estándares web y utiliza el protocolo HTTP para la comunicación de datos. Gira en torno a recursos donde cada componente es un recurso y se accede a un recurso mediante una interfaz común utilizando métodos estándar HTTP. REST fue introducido por primera vez por Roy Fielding en 2000.

En la arquitectura REST, un servidor REST simplemente proporciona acceso a los recursos y el cliente REST accede y presenta los recursos. Aquí, cada recurso se identifica mediante URI / ID globales. REST utiliza varias representaciones para representar un recurso como texto, JSON y XML. Hoy en día, JSON es el formato más popular que se utiliza en los servicios web.

Los siguientes métodos HTTP bien conocidos se utilizan comúnmente en la arquitectura basada en REST:

• GET - Proporciona acceso de solo lectura a un recurso.

• PUT : Se utiliza para actualizar un recurso existente o crear un nuevo recurso.

• DELETE - Se utiliza para eliminar un recurso.

• POST - Se utiliza para crear un nuevo recurso.

• OPTIONS : Se utiliza para obtener las operaciones admitidas en un recurso.

Un servicio web es una colección de protocolos y estándares abiertos que se utilizan para intercambiar datos entre aplicaciones o sistemas. Las aplicaciones de software escritas en varios lenguajes de programación y que se ejecutan en varias plataformas pueden utilizar servicios web para intercambiar datos a través de redes informáticas como Internet de una manera similar a la comunicación entre procesos en una sola computadora.

Los servicios web basados ​​en la arquitectura REST se conocen como servicios web RESTful. Estos servicios web utilizan métodos HTTP para implementar el concepto de arquitectura REST. Un servicio web RESTful generalmente define un URI, un identificador uniforme de recursos, un servicio, proporciona representación de recursos como JSON y un conjunto de métodos HTTP.

La arquitectura REST trata cada contenido como un recurso. Estos recursos pueden ser archivos de texto, páginas html, imágenes, videos o datos comerciales dinámicos. El servidor REST simplemente proporciona acceso a los recursos y el cliente REST accede y modifica los recursos. Aquí, cada recurso se identifica mediante URI / ID globales.

REST usa varias representaciones para representar un recurso donde texto, JSON, XML. XML y JSON son las representaciones de recursos más populares.

Los siguientes son puntos importantes que se deben considerar al diseñar un formato de representación de un recurso en un servicio web RESTful:

• Understandability - Tanto el servidor como el cliente deben poder comprender y utilizar el formato de representación del recurso.

• Completeness- El formato debe poder representar un recurso por completo. Por ejemplo, un recurso puede contener otro recurso. El formato debe poder representar estructuras de recursos simples y complejas.

• Linkablity - Un recurso puede tener un vínculo con otro recurso, un formato debe poder manejar tales situaciones.

Los servicios web RESTful utilizan el protocolo HTTP como medio de comunicación entre el cliente y el servidor.

Un cliente envía un mensaje en forma de solicitud HTTP y el servidor responde en forma de respuesta HTTP. Esta técnica se denomina mensajería. Estos mensajes contienen datos y metadatos del mensaje, es decir, información sobre el mensaje en sí.

Una solicitud HTTP tiene cinco partes principales:

• Verb - Indique métodos HTTP como GET, POST, DELETE, PUT, etc.

• URI - Identificador uniforme de recursos (URI) para identificar el recurso en el servidor.

• HTTP Version - Indique la versión de HTTP, por ejemplo HTTP v1.1.

• Request Header- Contiene metadatos para el mensaje de solicitud HTTP como pares clave-valor. Por ejemplo, tipo de cliente (o navegador), formato admitido por el cliente, formato del cuerpo del mensaje, configuración de la caché, etc.

• Request Body - Contenido del mensaje o representación de recursos.

Una respuesta HTTP tiene cuatro partes principales:

• Status/Response Code- Indique el estado del servidor para el recurso solicitado. Por ejemplo, 404 significa recurso no encontrado y 200 significa que la respuesta es correcta.

• HTTP Version - Indique la versión de HTTP, por ejemplo HTTP v1.1.

• Response Header- Contiene metadatos para el mensaje de respuesta HTTP como pares clave-valor. Por ejemplo, longitud del contenido, tipo de contenido, fecha de respuesta, tipo de servidor, etc.

• Response Body - Contenido del mensaje de respuesta o representación del recurso.

El direccionamiento se refiere a ubicar un recurso o varios recursos que se encuentran en el servidor. Es análogo localizar la dirección postal de una persona.

URI son las siglas de Uniform Resource Identifier. Cada recurso en la arquitectura REST se identifica por su URI.

El propósito de un URI es ubicar un recurso (s) en el servidor que aloja el servicio web.

Un URI tiene el siguiente formato:

<protocol>://<service-name>/<ResourceType>/<ResourceID>

VERB identifica la operación que se realizará en el recurso.

Los siguientes son puntos importantes que se deben considerar al diseñar un URI:

• Use Plural Noun- Usar sustantivo plural para definir recursos. Por ejemplo, hemos utilizado usuarios para identificar a los usuarios como un recurso.

• Avoid using spaces - Utilice guión bajo (_) o guión (-) cuando utilice un nombre de recurso largo, por ejemplo, utilice usuarios_autorizados en lugar de% 20usuarios autorizados.

• Use lowercase letters - Aunque el URI no distingue entre mayúsculas y minúsculas, es una buena práctica mantener la URL solo en minúsculas.

• Maintain Backward Compatibility- Dado que el servicio web es un servicio público, una URI una vez que se hace público debería estar siempre disponible. En caso de que el URI se actualice, redirija el URI anterior al nuevo URI utilizando el código de estado HTTP, 300.

• Use HTTP Verb- Utilice siempre verbos HTTP como GET, PUT y DELETE para realizar las operaciones en el recurso. No es bueno usar nombres de operaciones en URI.

Según la arquitectura REST, un servicio web RESTful no debe mantener un estado de cliente en el servidor. Esta restricción se llama apatridia. Es responsabilidad del cliente pasar su contexto al servidor y luego el servidor puede almacenar este contexto para procesar la solicitud adicional del cliente. Por ejemplo, la sesión mantenida por el servidor se identifica mediante el identificador de sesión pasado por el cliente.

Los siguientes son los beneficios de la apatridia en los servicios web RESTful:

• Los servicios web pueden tratar cada solicitud de método de forma independiente.

• Los servicios web no necesitan mantener las interacciones previas del cliente. Simplifica el diseño de aplicaciones.

• Como HTTP es en sí mismo un protocolo de ausencia de estado, los servicios web RESTful funcionan a la perfección con el protocolo HTTP.

A continuación se muestra la desventaja de la apatridia en los servicios web RESTful:

Los servicios web necesitan obtener información adicional en cada solicitud y luego interpretar para obtener el estado del cliente en caso de que se deban atender las interacciones del cliente.

Las operaciones idempotentes significan que su resultado siempre será el mismo sin importar cuántas veces se invoquen estas operaciones.

Las operaciones PUT y DELETE son idempotentes.

Las operaciones GET son de solo lectura y seguras.

Las operaciones PUT y POST son casi iguales, con la diferencia solo en el resultado donde la operación PUT es idempotente y la operación POST puede causar resultados diferentes.

Debe enumerar las operaciones admitidas en un servicio web y debe ser de solo lectura.

Debe devolver solo el encabezado HTTP, no el cuerpo y debe ser de solo lectura.

El almacenamiento en caché se refiere al almacenamiento de la respuesta del servidor en el propio cliente para que el cliente no necesite realizar una solicitud del mismo recurso al servidor una y otra vez. Una respuesta del servidor debe tener información sobre cómo se debe realizar el almacenamiento en caché para que un cliente almacene en caché la respuesta durante un período de tiempo o nunca almacene en caché la respuesta del servidor.

El encabezado de fecha proporciona la fecha y hora del recurso cuando se creó.

El encabezado Última modificación proporciona la fecha y hora del recurso cuando se modificó por última vez.

Cache-Control es el encabezado principal para controlar el almacenamiento en caché.

El encabezado expira establece la fecha de vencimiento y la hora de almacenamiento en caché.

La directiva pública indica que cualquier componente puede almacenar en caché el recurso.

La directiva privada indica que solo el cliente y el servidor pueden almacenar en caché el recurso, ningún intermediario puede almacenar en caché el recurso.

La directiva no-cache / no-store indica que el recurso no se puede almacenar en caché.

La directiva max-age indica que el almacenamiento en caché es válido hasta max-age en segundos. Después de esto, el cliente debe realizar otra solicitud.

La directiva must-revalidate proporciona una indicación al servidor para revalidar el recurso si ha pasado la edad máxima.

Mantenga siempre contenidos estáticos como imágenes, CSS, JavaScript en caché, con una fecha de vencimiento de 2 a 3 días. Nunca mantenga la fecha de caducidad demasiado alta.

Dado que los servicios web RESTful funcionan con rutas de URL HTTP, es muy importante proteger un servicio web RESTful de la misma manera que se protege un sitio web. Las siguientes son las mejores prácticas que se deben seguir al diseñar un servicio web RESTful:

• Validation- Validar todas las entradas en el servidor. Proteja su servidor contra ataques de inyección SQL o NoSQL.

• Session based authentication - Utilice la autenticación basada en sesión para autenticar a un usuario siempre que se realice una solicitud a un método de servicio web.

• No sensitive data in URL - Nunca use nombre de usuario, contraseña o token de sesión en la URL, estos valores deben pasarse al servicio web a través del método POST.

• Restriction on Method execution- Permitir el uso restringido de métodos como GET, POST, DELETE. El método GET no debería poder eliminar datos.

• Validate Malformed XML/JSON - Verifique que la entrada bien formada se haya pasado a un método de servicio web.

• Throw generic Error Messages - Un método de servicio web debe usar mensajes de error HTTP como 403 para mostrar acceso prohibido, etc.

El código de estado HTTP son códigos estándar y se refiere al estado predefinido de la tarea realizada en el servidor. Por ejemplo, HTTP Status 404 indica que el recurso solicitado no está presente en el servidor.

Significa, OK, muestra éxito.

Significa, CREADO, cuando un recurso se crea correctamente mediante la solicitud POST o PUT. Devolver el enlace al recurso recién creado usando el encabezado de ubicación

Significa, SIN CONTENIDO, cuando el cuerpo de la respuesta está vacío, por ejemplo, una solicitud DELETE.

Significa, NO MODIFICADO, que se utiliza para reducir el uso del ancho de banda de la red en caso de solicitudes GET condicionales. El cuerpo de respuesta debe estar vacío. Los encabezados deben tener fecha, ubicación, etc.

Significa, BAD REQUEST, indica que se proporciona una entrada no válida, por ejemplo, error de validación, datos faltantes.

Significa, PROHIBIDO, indica que el usuario no tiene acceso al método que se está utilizando, por ejemplo, eliminar el acceso sin derechos de administrador.

Significa, NO ENCONTRADO, indica que el método no está disponible.

Significa, CONFLICT, establece una situación de conflicto mientras se ejecuta el método, por ejemplo, agregando una entrada duplicada.

Significa, ERROR INTERNO DEL SERVIDOR, indica que el servidor ha lanzado alguna excepción al ejecutar el método.

JAX-RS son las siglas de JAVA API para RESTful Web Services. JAX-RS es una especificación y API de lenguaje de programación basada en JAVA para brindar soporte a los servicios web RESTful creados. Su versión 2.0 se lanzó el 24 de mayo de 2013. JAX-RS hace un uso intensivo de las anotaciones disponibles en Java SE 5 para simplificar el desarrollo de la creación y el despliegue de servicios web basados ​​en JAVA. También proporciona soporte para la creación de clientes para servicios web RESTful.