📘SAP FIORI - REST
Definición de REST
Es un modelo de arquitectura web basado en el protocolo HTTP, es más simple que otras arquitecturas como pueden ser XML-RPC o SOAP. Se logra mayor escalabilidad
La arquitectura REST se basa en recursos, donde cada uno de ellos está identificado de forma única. Un recurso sería un concepto importante de nuestro negocio (Facturas, orden de compra, orden de venta), también se lo suele denominar objeto de negocio.
Los servicios web que deben cumplir con las siguientes características:
- Es una Arquitectura cliente-servidor: una interfaz uniforme separa la capa de clientes de la de servidor.
- Por un lado la interfaz de usuario en una app
- Por otro lado los servicios para lo que la App va a proveer Lógica de negocio, puede tener los servicios en amazong , google, etc.
- Sin Estado(STATELESS): cada petición al servidor es tratada de manera totalmente independiente. El servidor no almacena datos, no existe la sesión de usuario. si el servicio requiere de seguridad/autenticación se tienen que pasar los datos para poder realizar la autenticación en cada llamada (usuario y contraseña, token, etc.). Cualquier solicitud de un cliente contiene toda la información necesaria para atender la solicitud.
- Información cacheable: las respuestas deben definirse como almacenables en caché o no almacenables en caché para evitar que los clientes utilicen datos obsoletos o inapropiados en respuesta a solicitudes posteriores adicionales. Para que el cliente recuerde la respuesta se usa max-age
- Servicios Uniformes: todos los servicios REST para poder interactuar con los recursos compartirán una forma de invocación uniforme utilizando los siguientes métodos HTML:
- GET: acceder a los distintos recursos.
- POST: creación de nuevos recursos.
- PUT: modificar los recursos existentes.
- DELETE: eliminar los recursos.
- Identificación de recurso: los recursos son identificados por una URI (Identificador Único del Recurso). Cada uno de los recursos debe tener un identificador único, el cual va a estar dado por su URL.
- Múltiples representaciones: independientemente de cómo esté almacenado. Un ejemplo sencillo para ilustrar este principio sería tener un recurso en formato XML y poder solicitarlo en JSON. Una representación del recurso son los datos, metadatos y los enlaces que se pueden usar, el cliente y servidor intercambian la representación de recursos.
Los hipermedios para representar la información suelen ser HTML, XML o JSON. Cuando se envía el dato se indica en la cabecera el tipo de contenido dentro del Content-Type se puede especificar: application/json, raw, text, etc.
Una vez recibida la solicitud de parte del cliente el servidor se encargada de manejar la representación y devolver el estado HTTP apropiado:
- HTTP 200: para mensajes OK.
- HTTP 400: cuando un recurso no está disponible.
- HTTP 500: Por un error interno del lado del servidor.
Ejemplo de una petición:
POST /MiApp/posts
Accept: application/json
Content-Type: application/json
Content-Length: 52
{"title":"Hola Mundo","body":"Soy un archivo Json"}
Ejemplo de una respuesta:
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 62
Connection: clocase
{"id":"1", "title":"Hola Mundo","body":"Soy un archivo Json"}
Disponibilidad Laboral: FullTime
