API - GEKO

Java – Spring Boot

Una interfaz hecha para desarrolladores que expone nuestros

recursos de una forma entendible y accesible para otros con
autorización Correspondiente a nuestra Información.

14 DE FEBRERO DE 2022
CRUZ ROJA C. SECCIONAL SANTANDER
Resumen

Es una interfaz de programación de aplicaciones (API o API web) que se ajusta a

los límites de la arquitectura REST y permite la interacción con los servicios web
de RESTfull, donde existe una llamada de datos y una respuesta, utilizando el
formato de Intercambio de datos entre aplicaciones o Sitios Web (JSON, XML).
ejemplo:
Realizaremos un consumo de API desde la aplicación GekoStudent, Donde por medio la
API accederemos de forma publica en cualquier Lugar con su respectivo esquema de
seguridad (User, password, token).
donde obtendremos todos los datos de estudiantes.
hacemos la petición al servidor por medio de la API
(http://cruzrojasantander.org/Geko/Student/students?pag=1)

Servidor – API REST

Request

GekoStudent – App 1
Answer

Request

Answer
GekoStudent – App 2
Respuesta de esta solicitud en formato JSON:

donde el primer parámetro es Student y el segundo una variable con la paginación.

{
“students”: {
{
“stu_id”: 1,
“stu_name”: “student1”,
“stu_email” : “email12@cruzrojasantander.org”
},
{
“stu_id”: 1,
“stu_name”: “student1”,
“stu_email” : “email12@cruzrojasantander.org”
}
}
Objetivos

1. Intercambio de datos entre empresas o instituciones externas que necesitan

acceder a nuestra información, con el fin de consolidar toda la información y
obtener un solo informe.
2. Ofrecer datos a aplicaciones que se ejecutan en un móvil.
3. Ofrecer datos a otros desarrolladores con un formato estándar.
4. Ofrecer datos de nuestra propia web o app.
Con esta implementación podemos decir que podremos compartir y crear nuevos recursos en
compañía con otras aplicaciones que estén ejecutándose en nuestra sede, ejemplo.

el sistema de Geo localización que tenemos para localizar cada vehículo y el sistema de
mantenimiento de GekoLogistica donde llevamos el control de mantenimiento y solicitudes de
mantenimiento, donde podemos hacer intercambio de datos y solo manejar una sola aplicación,
con dicha conexión.

en esta imagen podemos ver como varias empresas consumen los datos de la API.
implementando así el control de simultaneidad.

Concurrency Control

Servidor – API REST

Empresa 1

Empresa 2
HTTP Verbos

Debemos utilizar los HTTP verbs de forma adecuada para cuidar la semántica.
GET: Obtener datos. Ej: GET /geko/students? Pag=1234
PUT: Actualizar datos. Ej.: PUT /geko/inventario? Id=1
POST: Crear un nuevo recurso. Ej.: POST /geko/inventario
DELETE: Borrar el recurso. Ej: DELETE /geko/students? id=1

Llamadas al API
Las llamadas al API se implementan como peticiones HTTP, en las que:

La URL representa el recurso

http://www.cruzrojasantnder.org/geko/students?pag=1
El método (HTTP Verbs) representa la operación:

GET http://www.cruzrojasantnder.org/geko/students?pag=1
El código de estado HTTP representa el resultado:
200 OK HTTP/1.1
404 NOT FOUND HTTP/1.1

Creación de recursos
La URL estará “abierta” (el recurso todavía no existe y por tanto no tiene id)
El método debe ser POST
http://www.cruzrojasantnder.org/geko/students

Respuesta a la creación de recursos

Resultados posibles:
403 (Acceso prohibido)
400 (petición incorrecta, p.ej. falta un campo o su valor no es válido)
500 (Error del lado del servidor al intentar crear el recurso, p.ej. se ha caído la BD)
201 (Recurso creado correctamente)

Actualización de recursos

Método PUT
Según la ortodoxia REST, actualizar significaría cambiar TODOS los datos
PATCH es un nuevo método estándar HTTP (2010) pensado para cambiar solo
ciertos datos. Muchos framework de programación REST todavía no lo soportan
Resultados posibles
Errores ya vistos con POST
201 (Recurso creado, cuando le pasamos el id deseado al servidor)
200 (Recurso modificado correctamente)
Eliminar recursos

Método DELETE
Algunos resultados posibles:
200 OK
404 Not found
500 Server error
Tras ejecutar el DELETE con éxito, las siguientes peticiones GET a la URL del
recurso deberían devolver 404

Arquitectura REST
Reglas de una arquitectura REST
Interfaz uniforme
Peticiones sin estado
Cacheable
Separación de cliente y servidor
Sistema de Capas
Código bajo demanda (opcional)

Server

Los requerimientos principales para poner en funcionamiento seria obtener los paquetes
Tomcat en el servidor y JPA para los datos. o implementación de java en el servidor para
proyectos Sprint Boot.
A2 HOSTING
Alojamiento java y Spring Boot (Servidor vps).

AWS: (para uso exclusive de grandes cantidades de información) (opcional)

AWS SDK para Java simplifica el uso de los servicios de AWS al proporcionar un conjunto
de bibliotecas que son consistentes y familiares para los desarrolladores de Java. Brinda
soporte para las consideraciones del ciclo de vida de la API.
Compatibilidad con HTTP/2 y capa HTTP conectable
Las nuevas interfaces de programación aprovechan perfectamente las capacidades de
HTTP/2 y ofrecen nuevas formas de crear aplicaciones.

Google App Engine: (opcional)