REST API BÁSICO
Zapata Icart, Ernesto A.
Facultad Regional Paraná
Programación III
APLICACIONES TRADICIONALES WEB
Cliente GET /el-recurso Server
...
200 OK
Muestra la página
y el usuario GET /otro-recurso <html>código...</html>
clickea el link. ...
200 OK
Muestra la otra
página, ... <html>código...</html>
APLICACIONES TRADICIONALES WEB
La interface se arma con HTML & HTTP.
• Inconvenientes:
• El cliente debe entender HTTP y HTML.
• Toda la página web se reemplaza con otra.
• No hay manera de armar transiciones entre páginas.
• Los mismos datos son usados en múltiples responses.
• Ej.: Sólo código HTML para la capa de presentación.
APLICACIONES TRADICIONALES WEB
HTTP &
???
HTML
Cliente
Cliente Server
• Se puede usar HTTP & HTML pero no es óptimo.
• Los teléfonos móviles no usan HTML.
• Ej.: GET /users/3: Edad Ciudad
Nombre <h1>Ernesto</h1>
<p>Ernesto tiene 58 años y vive en Paraná.</p>
APPLICATION PROGRAMMING INTERFACE
Una GUI es una interface para seres humanos ↔ Comunicación máquina.
API GUI
Cliente Usuario
Server
Una API es una interface para una máquina ↔ Comunicación máquina
• Una API que hace uso de HTTP se llama Web API.
DIFERENTES TIPOS DE WEB APIS
• Remote Procedure Call, RPC.
• Los clientes pueden llamar a funciones en el server.
• Remote Method Invocation, RMI.
• Los clientes pueden llamar a métodos sobre objetos en el server.
• Representational State Transfer, REST.
• Los clientes pueden aplicar operaciones CRUD en recursos del server.
¿QUE ES REST?
Un estilo arquitectónico para sistemas distribuidos descrito por
Roy Thomas Fielding en su tesis doctoral del año 2000.
• Restricciones:
1. Client - Server
2. Stateless
3. Cache
4. Interface Uniforme
5. Layered System
6. Code-On-Demand
¿QUÉ SIGNIFICA REST?
El nombre "Representational State Transfer" pretende evocar
una imagen de cómo se comporta una aplicación web bien
diseñada: una red de páginas web (una máquina de estado
virtual), donde el usuario avanza a través de la aplicación
seleccionando enlaces (transiciones de estado) , lo que da como
resultado que la página siguiente (que representa el siguiente
estado de la aplicación) se transfiera al usuario y se presente
para su uso.
Del discurso de Roy.
¿QUÉ SIGNIFICA REST?
Id Nombre
1 Ernesto
2 Susana
3 Luis
Cliente GET /users/2 Server Usuarios
...
{"id": 2, "nombre": “Susana"}
Cambia el estado.
{"id": 2,
"nombre":
“Verónica"} PUT /users/2
{"id": 2, "nombre": “Verónica"}
USANDO HTTP COMO INTERFACE UNIFORME
• Use URIs para identificar recursos.
• Use métodos HTTP para especificar operaciones:
• Create: POST (o PUT) Mal Bien
• Retrieve: GET POST /login POST /login-sessions
• Update: PUT (o PATCH) POST /create-libros POST /libros
• Delete: DELETE GET /get-top-10-libros GET /top-10-libros
• Use headers HTTP Content-Type y Accept para especificar formato
de datos para los recursos.
• Use los códigos de status HTTP para indicar éxitos/fallos.
USANDO HTTP COMO INTERFACE UNIFORME
REST es un estilo arquitectónico, no una especificación.
• En la práctica, se puede usar de diferentes maneras.
• Pero algunas son mejores que otras.
Buenas recomendaciones:
• Web API Design - Crafting Interfaces that Developers Love
• [Link]
EJEMPLO REST
Id Nombre
Un server con información acerca de los usuarios. 1 Ernesto
• El método GET se usa para recuperar recursos. 2 Susana
• GET /users 3 Luis
• GET /users/2 Usuarios
• GET /users/pages/1 GET /users?page=1
• GET /users/genero/femenino GET /users?genero=femenino
• GET /users/edad/18 GET /users?edad=18
• GET /users/??? GET /users?genero=femenino&edad=18
• GET /users/2/nombre
• GET /users/2/mascotas
EJEMPLO REST Id Nombre
1 Ernesto
Un server con información acerca de los usuarios
2 Susana
• El método GET se usa para recuperar recursos. 3 Luis
• Con qué formato de datos? Se especifica en el header Accept! Usuarios
GET /users HTTP/1.1 HTTP/1.1 200 OK
Host: [Link] Content-Type: application/json
Accept: application/json Content-Length: 66
[
application/xml {"id": 1, "nombre": “Ernesto"},
fue popular antes de {"id": 2, "nombre": “Susana"}
JSON. ]
Id Nombre
EJEMPLO REST 1 Ernesto
2 Susana
Un server con información acerca de los usuarios 3 Luis
• El método POST se usa para crear recursos. Usuarios
• Con qué formato de datos? Especificado en los headers Accept y Content-Type!
POST /users HTTP/1.1 HTTP/1.1 201 Created
Host: [Link] Location: /users/3
Accept: application/json Content-Type: application/json
Content-Type: application/json Content-Length: 28
Content-Length: 49
{"id": 3, "nombre": “Augusto"}
<user>
<nombre>Augusto</nombre>
</user>
Id Nombre
EJEMPLO REST 1 Ernesto
2 Susana
Un server con información acerca de los usuarios 3 Luis
• El método PUT se usa para actualizar un recurso completo. Usuarios
PUT /users/3 HTTP/1.1 HTTP/1.1 204 No Content
Host: [Link]
Content-Type: application/json
Content-Length: 52 PUT puede ser usado para
crear un recurso si se
conoce de antemano la
<user>
URI.
<id>3</id>
<nombre>Cecilia</nombre>
</user>
Id Nombre
EJEMPLO REST 1 Ernesto
2 Susana
3 Luis
Un server con información acerca de los usuarios
Usuarios
• El método DELETE se usa para borrar un recurso.
DELETE /users/4 HTTP/1.1 HTTP/1.1 204 No Content
Host: [Link]
Id Nombre
EJEMPLO REST 1 Ernesto
2 Susana
Un server con información acerca de los usuarios 3 Luis
Usuarios
• El método PATCH se usa para actualizar parte de un recurso.
PATCH /users/1 HTTP/1.1 HTTP/1.1 204 No Content
Host: [Link]
Content-Type: application/json
Content-Length: 37
<user>
<name>Amanda</name>
</user>
Id Nombre
EJEMPLO REST 1 Ernesto
2 Susana
3 Luis
Un server con información acerca de los usuarios
Usuarios
• ¿Qué pasa si algo sale mal?
• Use los códigos de status HTTP para indicar éxito/fallo.
GET /users/999 HTTP/1.1 HTTP/1.1 404 Not Found
Host: [Link]
Accept: application/json
• Más códigos de status:
• [Link]
• Opcionalmente se pueden incluir los mensajes de error en el cuerpo del response.
DISEÑANDO UNA
API REST