REST
SOAP
BUSINESS
CORE
● Especificación de
protocolo
● Intercambio de
información mediante
XML
● Independiente del
protocolo de transporte
● Ampliamente usado en
la industria
● Excesivamente verboso
REST
Representational State Transfer
● Orientado a recursos
● Uso del protocolo HTTP (cliente-servidor)
● Separation of Concerns
● Stateless
● Mecanismos de caché
● Interfaz uniforme
Rest
HTTP
TCP
REST
Nuestro ejemplo
Nuestro ejemplo
Cuenta A Cuenta B
Transferencia
Saldo Saldo
HTTP
Petición
● Línea de petición
● Cabecera
● Cuerpo (opcional)
Respuesta
● Línea de estado
● Cabecera
● Cuerpo (opcional)
HTTP/1.1 200 OK
{ "response": “yeah!”}
POST /accountsService HTTP/1.1
{ "request": "give it to me!" }
HTTP
SH
Bank
POST /accountsService HTTP/1.1
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "response": [
{"account":
{"id": "cuentaA", "balance": "25M"}},
{"account":
{"id": "cuentaB", "balance": "12K"}}
]
}
HTTP
SH
Bank
POST /transferService HTTP/1.1
{
"service": "doTransfer",
"fromAccount": "cuentaA",
"toAccount": "cuentaB",
"amount": 1500,
"message": "Tengo un API rara."
}
HTTP/1.1 200 OK
{ "response": "ok" }
HTTP
SH
Bank
POST /accountsService HTTP/1.1
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "response": [
{"account":
{"id": "cuentaA", "balance": "25M"}},
{"account":
{"id": "cuentaB", "balance": "13.5K"}}
]
}
Recursos
● Uso de URI’s para identificar unívocamente un recurso
● Se usan URL’s para ello
● Podemos incluir en la cabecera negociación de
contenidos
Recursos
SH
Bank
POST /accounts HTTP/1.1
Content-type: application/json; charset=utf-8
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance":
"25M"},
{"id": "cuentaB", "balance": "12K"}
]
}
Recursos
SH
Bank
POST /accounts/cuentaA HTTP/1.1
{ "service": "getAccount" }
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"}
]
}
Recursos
SH
Bank
POST /transfers HTTP/1.1
{
"service": "doTransfer",
"transfer": {
"name": 1,
"from": "cuentaA",
"to": "cuentaB",
"amount": 1500,
"message": "Tengo un API psché."
}
}
HTTP/1.1 200 OK
{ "response": "ok" }
Recursos
SH
Bank
POST /accounts HTTP/1.1
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
]
}
Recursos
SH
Bank
POST /transfers/1 HTTP/1.1
{ "service": "getTransfer" }
HTTP/1.1 200 OK
{ "transfer": {
"name": 1,
"from": "cuentaA",
"to": "cuentaB",
"amount": 1500,
"message": "Tengo un API psché."
}
}
Recursos
¿Y si queremos devolver una mensaje de error?
{
"error": {
"name": "account.from.invalid",
"message": "La cuenta de origen no es válida"
}
}
Verbos HTTP
Los verbos https deben ser:
● Seguros
● Idempotentes
Verbo Seguro Idempotente
GET Sí Sí
POST No No
PUT No Sí
DELETE No Sí
Verbos HTTP
SH
Bank
GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
]
}
Verbos HTTP
SH
Bank
POST /transfers HTTP/1.1
{
"transfer": {
"from": "cuentaA",
"to": "cuentaB",
"amount": 1500,
"message": "Tengo un API Restful"
}
}
HTTP/1.1 200 OK
{ "response": "ok" }
Verbos HTTP
SH
Bank
GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
]
}
Verbos HTTP
Códigos de respuesta
2xx Éxito
➔ 200 Ok (puede adjuntar cuerpo)
➔ 204 No content
3xx Es necesaria una acción por parte del usuario para terminar
➔ 301 Moved permanently (adjunta cuerpo)
➔ 304 Not modified
4xx Error del cliente
➔ 404 Not found
➔ 409 Conflict (puede adjuntar cuerpo)
5xx Error en el servidor
➔ 504 Timeout
Hypermedia
SH
Bank
GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
],
"links": [
{"href": "/transfer",
"rel": "transfer",
"method": "POST"},
{"href": "/accounts",
"rel": "create",
"method": "POST"}
]}
Modelo de madurez de Richardson
● Nivel 1
Usar HTTP como protocolo
● Nivel 2
Obtener recursos y no POX
● Nivel 3
Usar los verbos HTTP
● Nivel 4
HATEOAS (Hypertext as the engine of the application state)
Recomendaciones
● Favorecer el principio de mínima sorpresa.
● Mantener la uniformidad.
● Documentación precisa.
o Cuerpos
o Códigos de error
o Parámetros
● Si existe alguna duda, buscar
implementaciones de referencia.
Implementaciones de referencia
● Paypal
● Twitter
● Amazon S3
● Facebook
● Google Apis
● Instagram
Frameworks
● Spring MVC
● RestEasy
● Ruby On Rails
● Laravel
● Yii
● WCF .Net
Distintos niveles de caché
Caché
Escalado
Caché distribuida
APIAPI API
Estrategias de testeo
Respuestas:
● Tipado
● Formato
● Consistencia
Funcionalidad:
● BDD (Cucumber)
● Tests de
integración
VUESTRO API ES VUESTRA TARJETA DE VISITA
Dudas
GRACIAS

Introducción a las API's Rest