![JSON
La sintaxis de JSON deriva de la sintaxis de notación de
objetos de JavaScript:
▰ Información como par “key”:“value”
▰ Datos separados por coma (,)
▰ Las llaves ({}) contienen objetos
▰ Los corchetes ([]) contienen listas
10
Reglas de Sintaxis](https://image.slidesharecdn.com/5-210410103710/85/5-2-api-rest-10-320.jpg)
![JSON
Las keys son “strings”.
Los value pueden ser:
▰ String "algún texto"
▰ Number 1 | -1 | 1.2 | -1.0
▰ Object {"key": "value"}
▰ List [1, "dos", {"val": 3.0}]
▰ Boolean true | false
▰ Null null
11
Tipos de datos](https://image.slidesharecdn.com/5-210410103710/85/5-2-api-rest-11-320.jpg)
![JSON
{
"lugar": "Universidad Nacional de Quilmes",
"coordenadas": {
"latitud": -34.706294,
"longitud": -58.278522
},
"distancias": [
{
"lugar": "Obelisco",
"kms": 14.81,
}, {
"lugar": "Mendoza",
"kms": 996.52
},
]
}
12](https://image.slidesharecdn.com/5-210410103710/85/5-2-api-rest-12-320.jpg)
![API REST
20
CRUD ⪼ Estándares ⪼ Respuesta
▰ POST /users
▻ 201 (Created)
▻ {“user”: Nuevo Usuario}
▰ GET /users
▻ 200 (OK)
▻ {“users”:[Listado]}
▰ GET /users/:id
▻ 200 (OK)
▻ {“user”: Usuario Pedido}
▰ PUT /users/:id
▻ 200 (OK)
▻ {“user”: Usuario Actualiz.}
▰ DELETE /users/:id
▻ 204 (No Content)
▻ Body: Vacío](https://image.slidesharecdn.com/5-210410103710/85/5-2-api-rest-20-320.jpg)
5.2. api-rest
- 1. API REST Construcción de Interfaces de Usuario 1er Cuatrimestre 2019
- 2. API ▰ Interfaz de Programación de Aplicaciones ▻ Application Programming Interface ▰ Conjunto de comandos, protocolos, funciones, objetos, etc... ▰ Provee estándares para facilitar la interacción con componentes ▰ Encapsula tareas complejas en otras más simples 2
- 3. API ▰ ¿Es una Interfaz de Usuario? ▰ ¿Quién es el Usuario? ▰ ¿Conocen ejemplos de APIs? 3
- 4. 4 Esquema
- 5. APIs Web ▰ Implementan servicios ▰ Exponen recursos ▰ Permite interactuar con multiplicidad de tecnologías ▰ Establecen un protocolo de comunicación ▰ Agregan una capa de seguridad 5
- 6. REST ▰ Transferencia de Estado Representacional ▻ REpresentational State Transfer ▰ Estilo de arquitectura de software que provee estándares para la interacción entre sistemas web ▰ Hace que la comunicación entre sistemas sea más simple 6
- 7. APIs RESTful ▰ Aquellas aplicaciones que son compatibles con los principios REST: ▻ Stateless ▻ Arquitectura Cliente-Servidor ▻ Uso de Caché ▻ Interface Uniforme 7
- 8. API REST ▰ Identificación del Recurso ▻ usuarios/, restaurants/, pedidos/, etc... ▰ Operaciones bien definidas ▻ GET, POST, PUT, DELETE, etc… ▰ Sintaxis Universal ▻ GET usuarios/, DELETE usuarios/, etc… ▰ Hypermedia ▻ application/json, text/html, etc... 8 Interface Uniforme
- 9. API REST Se necesita un formato definido para intercambiar información. Los dos formatos más extendidos son: 9 Formato de Intercambio JSON JavaScript Object Notation { "credentials": { "username": "hodor", "password": "hodor" } } XML Extensible Markup Language <credentials> <username>hodor</username> <password>hodor</password> </credentials>
- 10. JSON La sintaxis de JSON deriva de la sintaxis de notación de objetos de JavaScript: ▰ Información como par “key”:“value” ▰ Datos separados por coma (,) ▰ Las llaves ({}) contienen objetos ▰ Los corchetes ([]) contienen listas 10 Reglas de Sintaxis
- 11. JSON Las keys son “strings”. Los value pueden ser: ▰ String "algún texto" ▰ Number 1 | -1 | 1.2 | -1.0 ▰ Object {"key": "value"} ▰ List [1, "dos", {"val": 3.0}] ▰ Boolean true | false ▰ Null null 11 Tipos de datos
- 12. JSON { "lugar": "Universidad Nacional de Quilmes", "coordenadas": { "latitud": -34.706294, "longitud": -58.278522 }, "distancias": [ { "lugar": "Obelisco", "kms": 14.81, }, { "lugar": "Mendoza", "kms": 996.52 }, ] } 12
- 13. API REST Para cada REQUEST, en una API REST se define la estructura a la cual el cliente se debe ajustar para recuperar o modificar un recurso. En general consiste de: ▰ Verbo HTTP: define qué tipo de operación realizar ▰ Protocolo aceptado: HTTP 1.1, HTTP 1.0 ▰ Media Data aceptada: html, json, xml ▰ Encabezado: (opcional) permite pasar información extra ▰ Ruta al recurso ▰ Cuerpo de mensaje (opcional) que contiene datos 13 REQUESTs
- 14. API REST GET /users/23 HTTP/1.1 Accept: text/html, application/json 14 REQUESTs ⪼ Ejemplos POST /users HTTP/1.1 Accept: application/json Body: {“user”: { “name”: “Arya Stark” “email”: “nobody@braavos.org” }}
- 15. API REST Por cada REQUEST que se recibe se debe retornar un RESPONSE con la información necesaria para describir lo que ocurrió: ▰ HTTP Code acorde a lo sucedido con la ejecución ▰ Protocolo de respuesta ▰ Media-data de la respuesta ▰ Cuerpo de mensaje (opcional) con la información requerida 15 RESPONSEs
- 16. API REST GET /users/42 HTTP/1.1 Accept: text/html, application/json 16 RESPONSEs ⪼ Ejemplo (I) HTTP/1.1 200 (OK) Content-Type: application/json Body: {“user”: { “name”:“Hodor” “email”: “hodor@winterfell.com” }}
- 17. API REST POST /users HTTP/1.1 Body: {“user”: { “name”: “Arya Stark” “email”: “nobody@braavos.org” }} 17 RESPONSEs ⪼ Ejemplo (II) 201 (CREATED) Content-type: application/json
- 18. API REST 18 CRUD El modelo debe poder crear, leer, actualizar y eliminar recursos (Create, Read, Update, Delete). A esto se le llama CRUD. Es la funcionalidad mínima que se espera de un modelo. El paradigma CRUD es muy común en la construcción de aplicaciones web porque proporciona un modelo mental sobre los recursos, de manera que sean completos y utilizables.
- 19. API REST 19 CRUD ⪼ Estándares ⪼ Definición Los CRUD se suelen arman respetando un estándar de URIs y métodos: ▰ Crear POST /users ▰ Leer (todos) GET /users ▰ Leer (uno) GET /users/:id ▰ Actualizar PUT /users/:id ▰ Eliminar DELETE /users/:id
- 20. API REST 20 CRUD ⪼ Estándares ⪼ Respuesta ▰ POST /users ▻ 201 (Created) ▻ {“user”: Nuevo Usuario} ▰ GET /users ▻ 200 (OK) ▻ {“users”:[Listado]} ▰ GET /users/:id ▻ 200 (OK) ▻ {“user”: Usuario Pedido} ▰ PUT /users/:id ▻ 200 (OK) ▻ {“user”: Usuario Actualiz.} ▰ DELETE /users/:id ▻ 204 (No Content) ▻ Body: Vacío
- 21. API REST 21 CRUD ⪼ Estándares ⪼ Errores ▰ POST /users ▻ 404 (Not Found) ▻ 409 (Conflict) ▰ GET /users/:id ▻ 404 (Not Found) ▰ PUT /users/:id ▻ 404 (Not Found) ▻ 409 (Conflict) ▰ DELETE /users/:id ▻ 404 (Not Found) ▻ 405 (Method Not Allowed)
- 22. API REST 22 Errores Genéricos ▰ 401 (Unauthorized) ▰ 403 (Forbidden) ▰ 405 (Method Not Allowed) ▰ 500 (Internal Server Error)
- 23. API REST 23 Parámetros de consulta Muchas veces es necesario agregar información a la solicitud. Puede ser para filtrar una búsqueda o bien para que la respuesta incluya más o menos información. Para estos casos se suelen utilizar parámetros de consulta (query parameters). Se escriben como un par clave=valor separados por &.
- 24. API REST 24 Parámetros de consulta Ejemplos ▰ GET /users?mail=gmail&born_in=1990 ▰ GET /users/123?include=orders ▰ GET /users?page=3&per_page=25 No es buena práctica incluir parámetros en otros métodos que no sean de consulta (GET). Para enviar información (POST, PUT) se debe usar el body.
- 25. 25
- 26. LINKS ÚTILES 26 ▰ https://json.org/json-es.html ▰ https://www.restapitutorial.com/ ▰ https://jsonapi.org/ ▰ https://www.codecademy.com/articles/what-is-rest ▰ https://www.codecademy.com/articles/what-is-crud ▰ https://javalin.io/ ▰ https://github.com/toddmotto/public-apis
- 27. 27 ¿Preguntas?