Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Guiacutea praacutectica para
la publicacioacuten de
Datos Abiertos
usando APIs
2
Este estudio ha sido desarrollado en el marco de la Iniciativa
Aporta desarrollada por el Ministerio de Asuntos Econoacutemicos y
Transformacioacuten Digital a traveacutes de la Entidad Puacuteblica Empresarial
Redes
Contenido elaborado por
Carlos de la Fuente Garciacutea
experto en datos abiertos
El uso de este documento implica la expresa y plena aceptacioacuten
de las condiciones generales de reutilizacioacuten referidas en el aviso
legal que se muestra en httpdatosgobesesaviso-legal
Agradecimientos
Por sus contribuciones sugerencias y su disponibilidad en la
elaboracioacuten de esta guiacutea a
bull Alicia Martiacutenez Domingo (Experta en datos abiertos)
bull Mariano Luis Nieves Coello (CEH Data Scientist)
bull Juan Carlos Ballesteros Hermida (Arquitecto Software y
experto en datos abiertos)
bull Juliaacuten Moyano Collado (Coordinador Aragoacuten Open Data
Gobierno de Aragoacuten)
bull Jorge Loacutepez Peacuterez (Data Scientist)
bull Jorge Cimentada Baacuteez (Research Scientist)
bull Alberto Abella Garcia (Experto en datos abiertos)
Contenido01
02 Entendiendo las APIshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip05
Introduccioacuten04
04 Implementacioacuten de APIs en cataacutelogos de Datos Abiertoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip40
050607
APIs para el acceso a Datos Enlazadoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip42
APIs para el acceso a Servicios Web Geograacuteficoshelliphelliphelliphelliphellip45
Referenciashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip46
P1 Planificar el ciclo de vida14
P2 Usar URIs para identificar recursoshelliphelliphelliphellip15
P3 Gestioacuten de Resultadoshelliphelliphelliphelliphelliphelliphelliphelliphelliphellip19
P4 Especificacioacuten OpenApi (OAS)helliphelliphelliphelliphelliphellip21
P5 Recomendaciones sobre seguridad en las APIshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip23P6 Desacoplar servicios de Datoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip28
P11 Incorporar una documentacioacuten completahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip35
P8 Especificar el formato de entrega de Datos usando las cabeceras HTTPhelliphelliphelliphelliphellip30
P9 Usar cabeceras HTTP para elintercambio de informacioacutenhelliphelliphelliphelliphelliphelliphelliphellip32
P10 Definir interpretaciones comprensibles de coacutedigos de estadohelliphelliphellip33
03 Pautas de disentildeo e implementacioacuten de APIs 13
P7 Facilitar el acceso a Datos entiempo realhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip29
P12 Evitar rupturas de servicio o cambios abruptoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip37
P13 Evitar la degradacioacuten del rendimiento del servidorhelliphelliphelliphelliphelliphelliphelliphelliphelliphellip38
bull iquestQueacute es una API 05
bull iquestPara queacute sirve una API 05
bull iquestQueacute se necesita para usar una API 05
bull iquestCoacutemo se implementa una API 06
bull iquestCoacutemo funciona una API 08
bull iquestCuaacutendo es recomendable habilitar APIs para el acceso a datos abiertos helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip09
bull iquestDoacutende se estaacuten publicando APIs 10
bull Ecosistema FIWARE helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip11
bull iquestDoacutende ampliar informacioacuten sobre APIs helliphelliphelliphelliphelliphellip12
IntroduccioacutenLas Interfaces de Programacioacuten de Aplicaciones (API por sus siglas en ingleacutes) constituyen unode los servicios de intercambio de informacioacuten y acceso a datos maacutes comunes en la actualidadComplementan la disponibilidad de datos en ficheros descargables y aportan una serie deventajas que hacen que sea un medio de acceso y consumo de datos imprescindible encualquier Iniciativa de Datos Abiertos Ademaacutes es el mecanismo de acceso idoacuteneo parapublicar datos con alta frecuencia de actualizacioacuten como los datos en tiempo real o dinaacutemicos
Es habitual usar APIs para acceder a datos meteoroloacutegicos de transporte puacuteblico o losproducidos por sensores de monitorizacioacuten urbanos entre otros datos de alto valor Noobstante las APIs son adecuadas para consumir todo tipo de datos de forma automaacuteticasiendo posible ademaacutes ajustar la descarga exclusivamente a los datos requeridos
Las APIs son elementos software implementados para cubrir muacuteltiples propoacutesitos Esta guiacuteapone el foco en la disponibilidad de APIs en el contexto de los Datos Abiertos y estaorientacioacuten implica poner el eacutenfasis en las operaciones que permiten el acceso para lectura ydescarga de datos y no tanto en la capacidad de creacioacuten o modificacioacuten de datos por parte delos usuarios de la API
Igualmente existen diferentes alternativas en los modelos arquitectoacutenicos que inspiran eldisentildeo de las APIs Esta guiacutea explica el modelo API REST sobre HTTP que es el tipo de API maacutespopular y extendido No obstante hay otros modelos emergentes como GraphQL que estaacutelogrando un alto nivel de popularidad por su eficiencia cuando se interactuacutea con abundanciade recursos de informacioacuten y tambieacuten merecen espacial atencioacuten
Un buen disentildeo de APIs es esencial para maximizar su valor generar confianza en el sectorreutilizador y potenciar la generacioacuten de innovacioacuten a partir de los datos de mayor impactoPor esta razoacuten esta guiacutea propone una serie de contenidos que ayudaraacuten a entender el modelode disentildeo REST y a promover la aplicacioacuten de un compendio de pautas cuya aplicacioacutencontribuiraacute a generar interfaces de mayor calidad La guiacutea ademaacutes explica formas especificasde APIs para el consumo de datos enlazados utilizando puntos de acceso semaacutenticos y elfuncionamiento baacutesico de servicios web que facilitan la operacioacuten de datos espaciales Porotro lado se hace hincapieacute en una tendencia esencial para el disentildeo estandarizado utilizandola especificacioacuten OpenAPi
Aunque el aacutembito primordial de este documento se centra en la implementacioacuten eficiente deAPIs no se debe olvidar que se trata de servicios de Datos y por tanto es fundamental laaplicacioacuten de todas las buenas praacutecticas vinculadas a la calidad de datos en general En estesentido es recomendable complementar esta guiacutea con la lectura y aplicacioacuten de otras guiacuteasque orienten sobre la aplicacioacuten de pautas para asegurar la publicacioacuten de datos estructuradosde calidad
Por uacuteltimo hay que sentildealar que el puacuteblico objetivo de de esta guiacutea es principalmente elpromotor de Datos Abiertos cuyo objetivo es configurar servicios de datos a traveacutes de APIspor tanto es recomendable que el lector esteacute familiarizado con conocimientos baacutesicos sobreprogramacioacuten ndashfundamentalmente porque los usuarios primordiales de las APIs seraacutendesarrolladores- y la comprensioacuten del funcionamiento de la arquitectura cliente servidor quesoporta las peticiones y respuestas de informacioacuten a traveacutes de Internet
01
4
Entendiendo las APIs
02
iquestQueacute es una API
Una interfaz de programacioacuten de aplicaciones API es un mecanismo que permite lacomunicacioacuten e intercambio de informacioacuten entre sistemas
En el contexto de los Datos Abiertos el teacutermino generalmente se refiere a APIs sobre la Webdenominadas en algunos aacutembitos API Web que es un medio habitual para soportar elintercambio de informacioacuten dentro y entre organizaciones
Esta caracteriacutestica implica que una API ofrece un conjunto de funcionalidades sobre un servidoren la Web para ser utilizadas por aplicaciones cliente mediante el uso de procedimientosestaacutendar
iquestPara queacute sirve una API
Se usan para interactuar con el sistema deinformacioacuten de una organizacioacuten sin necesidadde un conocimiento de la estructura interna o dela tecnologiacutea utilizada en su desarrollo
Las APIs ofrecen una opcioacuten flexible de acceso alos datos respecto a la descarga de archivosaunque ambas opciones son compatibles y unaopcioacuten no excluye a la otra
Una ventaja de las APIs frente a la descarga dearchivos es que permite aplicar diferentesoperaciones durante el acceso y recuperacioacutende los datos El filtrado de datos o la seleccioacutendel formato de salida son operaciones habitualesen el consumo de datos viacutea API
iquestQueacute se necesita para usar unaAPI
Se necesitan conocer los mecanismos de uso de laAPI Para ello se pone a disposicioacuten de losusuarios una documentacioacuten que describe losdetalles teacutecnicos involucrados en su uso entreotros la forma de acceso y las operacionesnecesarias para interactuar con la API
La documentacioacuten de una API es uno de suselementos maacutes importantes y constituye unacuerdo entre las partes a modo de un contratoque describe el comportamiento y las condicionesde uso de la API especifica queacute operacionesestaacuten disponibles y queacute se va a obtener comorespuesta al invocarlas
5
Las APIs se implementan siguiendo alguacuten modelo arquitectoacutenico o guiacutea de disentildeo que permitedefinir las reglas que gobiernan la interaccioacuten entre sistemas Aunque existen diferentes modelosde implementacioacuten el foco de esta guiacutea es el disentildeo arquitectoacutenico REST (Representational StateTransfer) Las APIs que siguen este modelo de implementacioacuten se llaman RESTful APIs
Una caracteriacutestica relevante de este modelo es el uso de estaacutendares abiertos como HTTPHTTPSlo cual no vincula las implementaciones de la API en el servidor o de las aplicaciones cliente conninguna implementacioacuten concreta es decir ambos componentes se pueden implementar usandolenguajes de programacioacuten diferentes siempre que puedan formular solicitudes y entenderrespuestas usando el protocolo HTTP
Una API REST se puede implementar utilizando cualquier lenguaje de programacioacuten siendo losmaacutes habituales Java NET Python PHP Ruby o el maacutes reciente Nodejs En el apartado dereferencias de esta guiacutea se detalla una serie de herramientas de uso habitual para laimplementacioacuten y documentacioacuten de APIs
Las API REST se disentildean para exponer e interactuar con recursos que son objetos datos o serviciosa los que puede acceder un cliente Conceptualmente un recurso no debe asociarse con unaestructura fiacutesica de datos dado que podriacutea derivar de consultas internas a varias tablas de unabase de datos relacional y presentarse al cliente como una uacutenica entidad
API REST por tanto es una interfaz entre servidores y clientes para intercambiar representacionesde datos en la Web en diferentes formatos sobre todo JSON y XML
El uso del protocolo HTTP como meacutetodo de acceso y de URIs para identificar uniacutevocamenterecursos de datos de forma individual aportan una separacioacuten fundamental entre peticiones yrespuestas de datos logrando implementaciones de servicios y aplicaciones maacutes eficientes
02iquestCoacutemo se implementa una API
6
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
2
Este estudio ha sido desarrollado en el marco de la Iniciativa
Aporta desarrollada por el Ministerio de Asuntos Econoacutemicos y
Transformacioacuten Digital a traveacutes de la Entidad Puacuteblica Empresarial
Redes
Contenido elaborado por
Carlos de la Fuente Garciacutea
experto en datos abiertos
El uso de este documento implica la expresa y plena aceptacioacuten
de las condiciones generales de reutilizacioacuten referidas en el aviso
legal que se muestra en httpdatosgobesesaviso-legal
Agradecimientos
Por sus contribuciones sugerencias y su disponibilidad en la
elaboracioacuten de esta guiacutea a
bull Alicia Martiacutenez Domingo (Experta en datos abiertos)
bull Mariano Luis Nieves Coello (CEH Data Scientist)
bull Juan Carlos Ballesteros Hermida (Arquitecto Software y
experto en datos abiertos)
bull Juliaacuten Moyano Collado (Coordinador Aragoacuten Open Data
Gobierno de Aragoacuten)
bull Jorge Loacutepez Peacuterez (Data Scientist)
bull Jorge Cimentada Baacuteez (Research Scientist)
bull Alberto Abella Garcia (Experto en datos abiertos)
Contenido01
02 Entendiendo las APIshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip05
Introduccioacuten04
04 Implementacioacuten de APIs en cataacutelogos de Datos Abiertoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip40
050607
APIs para el acceso a Datos Enlazadoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip42
APIs para el acceso a Servicios Web Geograacuteficoshelliphelliphelliphelliphellip45
Referenciashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip46
P1 Planificar el ciclo de vida14
P2 Usar URIs para identificar recursoshelliphelliphelliphellip15
P3 Gestioacuten de Resultadoshelliphelliphelliphelliphelliphelliphelliphelliphelliphellip19
P4 Especificacioacuten OpenApi (OAS)helliphelliphelliphelliphelliphellip21
P5 Recomendaciones sobre seguridad en las APIshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip23P6 Desacoplar servicios de Datoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip28
P11 Incorporar una documentacioacuten completahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip35
P8 Especificar el formato de entrega de Datos usando las cabeceras HTTPhelliphelliphelliphelliphellip30
P9 Usar cabeceras HTTP para elintercambio de informacioacutenhelliphelliphelliphelliphelliphelliphelliphellip32
P10 Definir interpretaciones comprensibles de coacutedigos de estadohelliphelliphellip33
03 Pautas de disentildeo e implementacioacuten de APIs 13
P7 Facilitar el acceso a Datos entiempo realhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip29
P12 Evitar rupturas de servicio o cambios abruptoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip37
P13 Evitar la degradacioacuten del rendimiento del servidorhelliphelliphelliphelliphelliphelliphelliphelliphelliphellip38
bull iquestQueacute es una API 05
bull iquestPara queacute sirve una API 05
bull iquestQueacute se necesita para usar una API 05
bull iquestCoacutemo se implementa una API 06
bull iquestCoacutemo funciona una API 08
bull iquestCuaacutendo es recomendable habilitar APIs para el acceso a datos abiertos helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip09
bull iquestDoacutende se estaacuten publicando APIs 10
bull Ecosistema FIWARE helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip11
bull iquestDoacutende ampliar informacioacuten sobre APIs helliphelliphelliphelliphelliphellip12
IntroduccioacutenLas Interfaces de Programacioacuten de Aplicaciones (API por sus siglas en ingleacutes) constituyen unode los servicios de intercambio de informacioacuten y acceso a datos maacutes comunes en la actualidadComplementan la disponibilidad de datos en ficheros descargables y aportan una serie deventajas que hacen que sea un medio de acceso y consumo de datos imprescindible encualquier Iniciativa de Datos Abiertos Ademaacutes es el mecanismo de acceso idoacuteneo parapublicar datos con alta frecuencia de actualizacioacuten como los datos en tiempo real o dinaacutemicos
Es habitual usar APIs para acceder a datos meteoroloacutegicos de transporte puacuteblico o losproducidos por sensores de monitorizacioacuten urbanos entre otros datos de alto valor Noobstante las APIs son adecuadas para consumir todo tipo de datos de forma automaacuteticasiendo posible ademaacutes ajustar la descarga exclusivamente a los datos requeridos
Las APIs son elementos software implementados para cubrir muacuteltiples propoacutesitos Esta guiacuteapone el foco en la disponibilidad de APIs en el contexto de los Datos Abiertos y estaorientacioacuten implica poner el eacutenfasis en las operaciones que permiten el acceso para lectura ydescarga de datos y no tanto en la capacidad de creacioacuten o modificacioacuten de datos por parte delos usuarios de la API
Igualmente existen diferentes alternativas en los modelos arquitectoacutenicos que inspiran eldisentildeo de las APIs Esta guiacutea explica el modelo API REST sobre HTTP que es el tipo de API maacutespopular y extendido No obstante hay otros modelos emergentes como GraphQL que estaacutelogrando un alto nivel de popularidad por su eficiencia cuando se interactuacutea con abundanciade recursos de informacioacuten y tambieacuten merecen espacial atencioacuten
Un buen disentildeo de APIs es esencial para maximizar su valor generar confianza en el sectorreutilizador y potenciar la generacioacuten de innovacioacuten a partir de los datos de mayor impactoPor esta razoacuten esta guiacutea propone una serie de contenidos que ayudaraacuten a entender el modelode disentildeo REST y a promover la aplicacioacuten de un compendio de pautas cuya aplicacioacutencontribuiraacute a generar interfaces de mayor calidad La guiacutea ademaacutes explica formas especificasde APIs para el consumo de datos enlazados utilizando puntos de acceso semaacutenticos y elfuncionamiento baacutesico de servicios web que facilitan la operacioacuten de datos espaciales Porotro lado se hace hincapieacute en una tendencia esencial para el disentildeo estandarizado utilizandola especificacioacuten OpenAPi
Aunque el aacutembito primordial de este documento se centra en la implementacioacuten eficiente deAPIs no se debe olvidar que se trata de servicios de Datos y por tanto es fundamental laaplicacioacuten de todas las buenas praacutecticas vinculadas a la calidad de datos en general En estesentido es recomendable complementar esta guiacutea con la lectura y aplicacioacuten de otras guiacuteasque orienten sobre la aplicacioacuten de pautas para asegurar la publicacioacuten de datos estructuradosde calidad
Por uacuteltimo hay que sentildealar que el puacuteblico objetivo de de esta guiacutea es principalmente elpromotor de Datos Abiertos cuyo objetivo es configurar servicios de datos a traveacutes de APIspor tanto es recomendable que el lector esteacute familiarizado con conocimientos baacutesicos sobreprogramacioacuten ndashfundamentalmente porque los usuarios primordiales de las APIs seraacutendesarrolladores- y la comprensioacuten del funcionamiento de la arquitectura cliente servidor quesoporta las peticiones y respuestas de informacioacuten a traveacutes de Internet
01
4
Entendiendo las APIs
02
iquestQueacute es una API
Una interfaz de programacioacuten de aplicaciones API es un mecanismo que permite lacomunicacioacuten e intercambio de informacioacuten entre sistemas
En el contexto de los Datos Abiertos el teacutermino generalmente se refiere a APIs sobre la Webdenominadas en algunos aacutembitos API Web que es un medio habitual para soportar elintercambio de informacioacuten dentro y entre organizaciones
Esta caracteriacutestica implica que una API ofrece un conjunto de funcionalidades sobre un servidoren la Web para ser utilizadas por aplicaciones cliente mediante el uso de procedimientosestaacutendar
iquestPara queacute sirve una API
Se usan para interactuar con el sistema deinformacioacuten de una organizacioacuten sin necesidadde un conocimiento de la estructura interna o dela tecnologiacutea utilizada en su desarrollo
Las APIs ofrecen una opcioacuten flexible de acceso alos datos respecto a la descarga de archivosaunque ambas opciones son compatibles y unaopcioacuten no excluye a la otra
Una ventaja de las APIs frente a la descarga dearchivos es que permite aplicar diferentesoperaciones durante el acceso y recuperacioacutende los datos El filtrado de datos o la seleccioacutendel formato de salida son operaciones habitualesen el consumo de datos viacutea API
iquestQueacute se necesita para usar unaAPI
Se necesitan conocer los mecanismos de uso de laAPI Para ello se pone a disposicioacuten de losusuarios una documentacioacuten que describe losdetalles teacutecnicos involucrados en su uso entreotros la forma de acceso y las operacionesnecesarias para interactuar con la API
La documentacioacuten de una API es uno de suselementos maacutes importantes y constituye unacuerdo entre las partes a modo de un contratoque describe el comportamiento y las condicionesde uso de la API especifica queacute operacionesestaacuten disponibles y queacute se va a obtener comorespuesta al invocarlas
5
Las APIs se implementan siguiendo alguacuten modelo arquitectoacutenico o guiacutea de disentildeo que permitedefinir las reglas que gobiernan la interaccioacuten entre sistemas Aunque existen diferentes modelosde implementacioacuten el foco de esta guiacutea es el disentildeo arquitectoacutenico REST (Representational StateTransfer) Las APIs que siguen este modelo de implementacioacuten se llaman RESTful APIs
Una caracteriacutestica relevante de este modelo es el uso de estaacutendares abiertos como HTTPHTTPSlo cual no vincula las implementaciones de la API en el servidor o de las aplicaciones cliente conninguna implementacioacuten concreta es decir ambos componentes se pueden implementar usandolenguajes de programacioacuten diferentes siempre que puedan formular solicitudes y entenderrespuestas usando el protocolo HTTP
Una API REST se puede implementar utilizando cualquier lenguaje de programacioacuten siendo losmaacutes habituales Java NET Python PHP Ruby o el maacutes reciente Nodejs En el apartado dereferencias de esta guiacutea se detalla una serie de herramientas de uso habitual para laimplementacioacuten y documentacioacuten de APIs
Las API REST se disentildean para exponer e interactuar con recursos que son objetos datos o serviciosa los que puede acceder un cliente Conceptualmente un recurso no debe asociarse con unaestructura fiacutesica de datos dado que podriacutea derivar de consultas internas a varias tablas de unabase de datos relacional y presentarse al cliente como una uacutenica entidad
API REST por tanto es una interfaz entre servidores y clientes para intercambiar representacionesde datos en la Web en diferentes formatos sobre todo JSON y XML
El uso del protocolo HTTP como meacutetodo de acceso y de URIs para identificar uniacutevocamenterecursos de datos de forma individual aportan una separacioacuten fundamental entre peticiones yrespuestas de datos logrando implementaciones de servicios y aplicaciones maacutes eficientes
02iquestCoacutemo se implementa una API
6
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Contenido01
02 Entendiendo las APIshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip05
Introduccioacuten04
04 Implementacioacuten de APIs en cataacutelogos de Datos Abiertoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip40
050607
APIs para el acceso a Datos Enlazadoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip42
APIs para el acceso a Servicios Web Geograacuteficoshelliphelliphelliphelliphellip45
Referenciashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip46
P1 Planificar el ciclo de vida14
P2 Usar URIs para identificar recursoshelliphelliphelliphellip15
P3 Gestioacuten de Resultadoshelliphelliphelliphelliphelliphelliphelliphelliphelliphellip19
P4 Especificacioacuten OpenApi (OAS)helliphelliphelliphelliphelliphellip21
P5 Recomendaciones sobre seguridad en las APIshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip23P6 Desacoplar servicios de Datoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip28
P11 Incorporar una documentacioacuten completahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip35
P8 Especificar el formato de entrega de Datos usando las cabeceras HTTPhelliphelliphelliphelliphellip30
P9 Usar cabeceras HTTP para elintercambio de informacioacutenhelliphelliphelliphelliphelliphelliphelliphellip32
P10 Definir interpretaciones comprensibles de coacutedigos de estadohelliphelliphellip33
03 Pautas de disentildeo e implementacioacuten de APIs 13
P7 Facilitar el acceso a Datos entiempo realhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip29
P12 Evitar rupturas de servicio o cambios abruptoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip37
P13 Evitar la degradacioacuten del rendimiento del servidorhelliphelliphelliphelliphelliphelliphelliphelliphelliphellip38
bull iquestQueacute es una API 05
bull iquestPara queacute sirve una API 05
bull iquestQueacute se necesita para usar una API 05
bull iquestCoacutemo se implementa una API 06
bull iquestCoacutemo funciona una API 08
bull iquestCuaacutendo es recomendable habilitar APIs para el acceso a datos abiertos helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip09
bull iquestDoacutende se estaacuten publicando APIs 10
bull Ecosistema FIWARE helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip11
bull iquestDoacutende ampliar informacioacuten sobre APIs helliphelliphelliphelliphelliphellip12
IntroduccioacutenLas Interfaces de Programacioacuten de Aplicaciones (API por sus siglas en ingleacutes) constituyen unode los servicios de intercambio de informacioacuten y acceso a datos maacutes comunes en la actualidadComplementan la disponibilidad de datos en ficheros descargables y aportan una serie deventajas que hacen que sea un medio de acceso y consumo de datos imprescindible encualquier Iniciativa de Datos Abiertos Ademaacutes es el mecanismo de acceso idoacuteneo parapublicar datos con alta frecuencia de actualizacioacuten como los datos en tiempo real o dinaacutemicos
Es habitual usar APIs para acceder a datos meteoroloacutegicos de transporte puacuteblico o losproducidos por sensores de monitorizacioacuten urbanos entre otros datos de alto valor Noobstante las APIs son adecuadas para consumir todo tipo de datos de forma automaacuteticasiendo posible ademaacutes ajustar la descarga exclusivamente a los datos requeridos
Las APIs son elementos software implementados para cubrir muacuteltiples propoacutesitos Esta guiacuteapone el foco en la disponibilidad de APIs en el contexto de los Datos Abiertos y estaorientacioacuten implica poner el eacutenfasis en las operaciones que permiten el acceso para lectura ydescarga de datos y no tanto en la capacidad de creacioacuten o modificacioacuten de datos por parte delos usuarios de la API
Igualmente existen diferentes alternativas en los modelos arquitectoacutenicos que inspiran eldisentildeo de las APIs Esta guiacutea explica el modelo API REST sobre HTTP que es el tipo de API maacutespopular y extendido No obstante hay otros modelos emergentes como GraphQL que estaacutelogrando un alto nivel de popularidad por su eficiencia cuando se interactuacutea con abundanciade recursos de informacioacuten y tambieacuten merecen espacial atencioacuten
Un buen disentildeo de APIs es esencial para maximizar su valor generar confianza en el sectorreutilizador y potenciar la generacioacuten de innovacioacuten a partir de los datos de mayor impactoPor esta razoacuten esta guiacutea propone una serie de contenidos que ayudaraacuten a entender el modelode disentildeo REST y a promover la aplicacioacuten de un compendio de pautas cuya aplicacioacutencontribuiraacute a generar interfaces de mayor calidad La guiacutea ademaacutes explica formas especificasde APIs para el consumo de datos enlazados utilizando puntos de acceso semaacutenticos y elfuncionamiento baacutesico de servicios web que facilitan la operacioacuten de datos espaciales Porotro lado se hace hincapieacute en una tendencia esencial para el disentildeo estandarizado utilizandola especificacioacuten OpenAPi
Aunque el aacutembito primordial de este documento se centra en la implementacioacuten eficiente deAPIs no se debe olvidar que se trata de servicios de Datos y por tanto es fundamental laaplicacioacuten de todas las buenas praacutecticas vinculadas a la calidad de datos en general En estesentido es recomendable complementar esta guiacutea con la lectura y aplicacioacuten de otras guiacuteasque orienten sobre la aplicacioacuten de pautas para asegurar la publicacioacuten de datos estructuradosde calidad
Por uacuteltimo hay que sentildealar que el puacuteblico objetivo de de esta guiacutea es principalmente elpromotor de Datos Abiertos cuyo objetivo es configurar servicios de datos a traveacutes de APIspor tanto es recomendable que el lector esteacute familiarizado con conocimientos baacutesicos sobreprogramacioacuten ndashfundamentalmente porque los usuarios primordiales de las APIs seraacutendesarrolladores- y la comprensioacuten del funcionamiento de la arquitectura cliente servidor quesoporta las peticiones y respuestas de informacioacuten a traveacutes de Internet
01
4
Entendiendo las APIs
02
iquestQueacute es una API
Una interfaz de programacioacuten de aplicaciones API es un mecanismo que permite lacomunicacioacuten e intercambio de informacioacuten entre sistemas
En el contexto de los Datos Abiertos el teacutermino generalmente se refiere a APIs sobre la Webdenominadas en algunos aacutembitos API Web que es un medio habitual para soportar elintercambio de informacioacuten dentro y entre organizaciones
Esta caracteriacutestica implica que una API ofrece un conjunto de funcionalidades sobre un servidoren la Web para ser utilizadas por aplicaciones cliente mediante el uso de procedimientosestaacutendar
iquestPara queacute sirve una API
Se usan para interactuar con el sistema deinformacioacuten de una organizacioacuten sin necesidadde un conocimiento de la estructura interna o dela tecnologiacutea utilizada en su desarrollo
Las APIs ofrecen una opcioacuten flexible de acceso alos datos respecto a la descarga de archivosaunque ambas opciones son compatibles y unaopcioacuten no excluye a la otra
Una ventaja de las APIs frente a la descarga dearchivos es que permite aplicar diferentesoperaciones durante el acceso y recuperacioacutende los datos El filtrado de datos o la seleccioacutendel formato de salida son operaciones habitualesen el consumo de datos viacutea API
iquestQueacute se necesita para usar unaAPI
Se necesitan conocer los mecanismos de uso de laAPI Para ello se pone a disposicioacuten de losusuarios una documentacioacuten que describe losdetalles teacutecnicos involucrados en su uso entreotros la forma de acceso y las operacionesnecesarias para interactuar con la API
La documentacioacuten de una API es uno de suselementos maacutes importantes y constituye unacuerdo entre las partes a modo de un contratoque describe el comportamiento y las condicionesde uso de la API especifica queacute operacionesestaacuten disponibles y queacute se va a obtener comorespuesta al invocarlas
5
Las APIs se implementan siguiendo alguacuten modelo arquitectoacutenico o guiacutea de disentildeo que permitedefinir las reglas que gobiernan la interaccioacuten entre sistemas Aunque existen diferentes modelosde implementacioacuten el foco de esta guiacutea es el disentildeo arquitectoacutenico REST (Representational StateTransfer) Las APIs que siguen este modelo de implementacioacuten se llaman RESTful APIs
Una caracteriacutestica relevante de este modelo es el uso de estaacutendares abiertos como HTTPHTTPSlo cual no vincula las implementaciones de la API en el servidor o de las aplicaciones cliente conninguna implementacioacuten concreta es decir ambos componentes se pueden implementar usandolenguajes de programacioacuten diferentes siempre que puedan formular solicitudes y entenderrespuestas usando el protocolo HTTP
Una API REST se puede implementar utilizando cualquier lenguaje de programacioacuten siendo losmaacutes habituales Java NET Python PHP Ruby o el maacutes reciente Nodejs En el apartado dereferencias de esta guiacutea se detalla una serie de herramientas de uso habitual para laimplementacioacuten y documentacioacuten de APIs
Las API REST se disentildean para exponer e interactuar con recursos que son objetos datos o serviciosa los que puede acceder un cliente Conceptualmente un recurso no debe asociarse con unaestructura fiacutesica de datos dado que podriacutea derivar de consultas internas a varias tablas de unabase de datos relacional y presentarse al cliente como una uacutenica entidad
API REST por tanto es una interfaz entre servidores y clientes para intercambiar representacionesde datos en la Web en diferentes formatos sobre todo JSON y XML
El uso del protocolo HTTP como meacutetodo de acceso y de URIs para identificar uniacutevocamenterecursos de datos de forma individual aportan una separacioacuten fundamental entre peticiones yrespuestas de datos logrando implementaciones de servicios y aplicaciones maacutes eficientes
02iquestCoacutemo se implementa una API
6
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
IntroduccioacutenLas Interfaces de Programacioacuten de Aplicaciones (API por sus siglas en ingleacutes) constituyen unode los servicios de intercambio de informacioacuten y acceso a datos maacutes comunes en la actualidadComplementan la disponibilidad de datos en ficheros descargables y aportan una serie deventajas que hacen que sea un medio de acceso y consumo de datos imprescindible encualquier Iniciativa de Datos Abiertos Ademaacutes es el mecanismo de acceso idoacuteneo parapublicar datos con alta frecuencia de actualizacioacuten como los datos en tiempo real o dinaacutemicos
Es habitual usar APIs para acceder a datos meteoroloacutegicos de transporte puacuteblico o losproducidos por sensores de monitorizacioacuten urbanos entre otros datos de alto valor Noobstante las APIs son adecuadas para consumir todo tipo de datos de forma automaacuteticasiendo posible ademaacutes ajustar la descarga exclusivamente a los datos requeridos
Las APIs son elementos software implementados para cubrir muacuteltiples propoacutesitos Esta guiacuteapone el foco en la disponibilidad de APIs en el contexto de los Datos Abiertos y estaorientacioacuten implica poner el eacutenfasis en las operaciones que permiten el acceso para lectura ydescarga de datos y no tanto en la capacidad de creacioacuten o modificacioacuten de datos por parte delos usuarios de la API
Igualmente existen diferentes alternativas en los modelos arquitectoacutenicos que inspiran eldisentildeo de las APIs Esta guiacutea explica el modelo API REST sobre HTTP que es el tipo de API maacutespopular y extendido No obstante hay otros modelos emergentes como GraphQL que estaacutelogrando un alto nivel de popularidad por su eficiencia cuando se interactuacutea con abundanciade recursos de informacioacuten y tambieacuten merecen espacial atencioacuten
Un buen disentildeo de APIs es esencial para maximizar su valor generar confianza en el sectorreutilizador y potenciar la generacioacuten de innovacioacuten a partir de los datos de mayor impactoPor esta razoacuten esta guiacutea propone una serie de contenidos que ayudaraacuten a entender el modelode disentildeo REST y a promover la aplicacioacuten de un compendio de pautas cuya aplicacioacutencontribuiraacute a generar interfaces de mayor calidad La guiacutea ademaacutes explica formas especificasde APIs para el consumo de datos enlazados utilizando puntos de acceso semaacutenticos y elfuncionamiento baacutesico de servicios web que facilitan la operacioacuten de datos espaciales Porotro lado se hace hincapieacute en una tendencia esencial para el disentildeo estandarizado utilizandola especificacioacuten OpenAPi
Aunque el aacutembito primordial de este documento se centra en la implementacioacuten eficiente deAPIs no se debe olvidar que se trata de servicios de Datos y por tanto es fundamental laaplicacioacuten de todas las buenas praacutecticas vinculadas a la calidad de datos en general En estesentido es recomendable complementar esta guiacutea con la lectura y aplicacioacuten de otras guiacuteasque orienten sobre la aplicacioacuten de pautas para asegurar la publicacioacuten de datos estructuradosde calidad
Por uacuteltimo hay que sentildealar que el puacuteblico objetivo de de esta guiacutea es principalmente elpromotor de Datos Abiertos cuyo objetivo es configurar servicios de datos a traveacutes de APIspor tanto es recomendable que el lector esteacute familiarizado con conocimientos baacutesicos sobreprogramacioacuten ndashfundamentalmente porque los usuarios primordiales de las APIs seraacutendesarrolladores- y la comprensioacuten del funcionamiento de la arquitectura cliente servidor quesoporta las peticiones y respuestas de informacioacuten a traveacutes de Internet
01
4
Entendiendo las APIs
02
iquestQueacute es una API
Una interfaz de programacioacuten de aplicaciones API es un mecanismo que permite lacomunicacioacuten e intercambio de informacioacuten entre sistemas
En el contexto de los Datos Abiertos el teacutermino generalmente se refiere a APIs sobre la Webdenominadas en algunos aacutembitos API Web que es un medio habitual para soportar elintercambio de informacioacuten dentro y entre organizaciones
Esta caracteriacutestica implica que una API ofrece un conjunto de funcionalidades sobre un servidoren la Web para ser utilizadas por aplicaciones cliente mediante el uso de procedimientosestaacutendar
iquestPara queacute sirve una API
Se usan para interactuar con el sistema deinformacioacuten de una organizacioacuten sin necesidadde un conocimiento de la estructura interna o dela tecnologiacutea utilizada en su desarrollo
Las APIs ofrecen una opcioacuten flexible de acceso alos datos respecto a la descarga de archivosaunque ambas opciones son compatibles y unaopcioacuten no excluye a la otra
Una ventaja de las APIs frente a la descarga dearchivos es que permite aplicar diferentesoperaciones durante el acceso y recuperacioacutende los datos El filtrado de datos o la seleccioacutendel formato de salida son operaciones habitualesen el consumo de datos viacutea API
iquestQueacute se necesita para usar unaAPI
Se necesitan conocer los mecanismos de uso de laAPI Para ello se pone a disposicioacuten de losusuarios una documentacioacuten que describe losdetalles teacutecnicos involucrados en su uso entreotros la forma de acceso y las operacionesnecesarias para interactuar con la API
La documentacioacuten de una API es uno de suselementos maacutes importantes y constituye unacuerdo entre las partes a modo de un contratoque describe el comportamiento y las condicionesde uso de la API especifica queacute operacionesestaacuten disponibles y queacute se va a obtener comorespuesta al invocarlas
5
Las APIs se implementan siguiendo alguacuten modelo arquitectoacutenico o guiacutea de disentildeo que permitedefinir las reglas que gobiernan la interaccioacuten entre sistemas Aunque existen diferentes modelosde implementacioacuten el foco de esta guiacutea es el disentildeo arquitectoacutenico REST (Representational StateTransfer) Las APIs que siguen este modelo de implementacioacuten se llaman RESTful APIs
Una caracteriacutestica relevante de este modelo es el uso de estaacutendares abiertos como HTTPHTTPSlo cual no vincula las implementaciones de la API en el servidor o de las aplicaciones cliente conninguna implementacioacuten concreta es decir ambos componentes se pueden implementar usandolenguajes de programacioacuten diferentes siempre que puedan formular solicitudes y entenderrespuestas usando el protocolo HTTP
Una API REST se puede implementar utilizando cualquier lenguaje de programacioacuten siendo losmaacutes habituales Java NET Python PHP Ruby o el maacutes reciente Nodejs En el apartado dereferencias de esta guiacutea se detalla una serie de herramientas de uso habitual para laimplementacioacuten y documentacioacuten de APIs
Las API REST se disentildean para exponer e interactuar con recursos que son objetos datos o serviciosa los que puede acceder un cliente Conceptualmente un recurso no debe asociarse con unaestructura fiacutesica de datos dado que podriacutea derivar de consultas internas a varias tablas de unabase de datos relacional y presentarse al cliente como una uacutenica entidad
API REST por tanto es una interfaz entre servidores y clientes para intercambiar representacionesde datos en la Web en diferentes formatos sobre todo JSON y XML
El uso del protocolo HTTP como meacutetodo de acceso y de URIs para identificar uniacutevocamenterecursos de datos de forma individual aportan una separacioacuten fundamental entre peticiones yrespuestas de datos logrando implementaciones de servicios y aplicaciones maacutes eficientes
02iquestCoacutemo se implementa una API
6
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Entendiendo las APIs
02
iquestQueacute es una API
Una interfaz de programacioacuten de aplicaciones API es un mecanismo que permite lacomunicacioacuten e intercambio de informacioacuten entre sistemas
En el contexto de los Datos Abiertos el teacutermino generalmente se refiere a APIs sobre la Webdenominadas en algunos aacutembitos API Web que es un medio habitual para soportar elintercambio de informacioacuten dentro y entre organizaciones
Esta caracteriacutestica implica que una API ofrece un conjunto de funcionalidades sobre un servidoren la Web para ser utilizadas por aplicaciones cliente mediante el uso de procedimientosestaacutendar
iquestPara queacute sirve una API
Se usan para interactuar con el sistema deinformacioacuten de una organizacioacuten sin necesidadde un conocimiento de la estructura interna o dela tecnologiacutea utilizada en su desarrollo
Las APIs ofrecen una opcioacuten flexible de acceso alos datos respecto a la descarga de archivosaunque ambas opciones son compatibles y unaopcioacuten no excluye a la otra
Una ventaja de las APIs frente a la descarga dearchivos es que permite aplicar diferentesoperaciones durante el acceso y recuperacioacutende los datos El filtrado de datos o la seleccioacutendel formato de salida son operaciones habitualesen el consumo de datos viacutea API
iquestQueacute se necesita para usar unaAPI
Se necesitan conocer los mecanismos de uso de laAPI Para ello se pone a disposicioacuten de losusuarios una documentacioacuten que describe losdetalles teacutecnicos involucrados en su uso entreotros la forma de acceso y las operacionesnecesarias para interactuar con la API
La documentacioacuten de una API es uno de suselementos maacutes importantes y constituye unacuerdo entre las partes a modo de un contratoque describe el comportamiento y las condicionesde uso de la API especifica queacute operacionesestaacuten disponibles y queacute se va a obtener comorespuesta al invocarlas
5
Las APIs se implementan siguiendo alguacuten modelo arquitectoacutenico o guiacutea de disentildeo que permitedefinir las reglas que gobiernan la interaccioacuten entre sistemas Aunque existen diferentes modelosde implementacioacuten el foco de esta guiacutea es el disentildeo arquitectoacutenico REST (Representational StateTransfer) Las APIs que siguen este modelo de implementacioacuten se llaman RESTful APIs
Una caracteriacutestica relevante de este modelo es el uso de estaacutendares abiertos como HTTPHTTPSlo cual no vincula las implementaciones de la API en el servidor o de las aplicaciones cliente conninguna implementacioacuten concreta es decir ambos componentes se pueden implementar usandolenguajes de programacioacuten diferentes siempre que puedan formular solicitudes y entenderrespuestas usando el protocolo HTTP
Una API REST se puede implementar utilizando cualquier lenguaje de programacioacuten siendo losmaacutes habituales Java NET Python PHP Ruby o el maacutes reciente Nodejs En el apartado dereferencias de esta guiacutea se detalla una serie de herramientas de uso habitual para laimplementacioacuten y documentacioacuten de APIs
Las API REST se disentildean para exponer e interactuar con recursos que son objetos datos o serviciosa los que puede acceder un cliente Conceptualmente un recurso no debe asociarse con unaestructura fiacutesica de datos dado que podriacutea derivar de consultas internas a varias tablas de unabase de datos relacional y presentarse al cliente como una uacutenica entidad
API REST por tanto es una interfaz entre servidores y clientes para intercambiar representacionesde datos en la Web en diferentes formatos sobre todo JSON y XML
El uso del protocolo HTTP como meacutetodo de acceso y de URIs para identificar uniacutevocamenterecursos de datos de forma individual aportan una separacioacuten fundamental entre peticiones yrespuestas de datos logrando implementaciones de servicios y aplicaciones maacutes eficientes
02iquestCoacutemo se implementa una API
6
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Las APIs se implementan siguiendo alguacuten modelo arquitectoacutenico o guiacutea de disentildeo que permitedefinir las reglas que gobiernan la interaccioacuten entre sistemas Aunque existen diferentes modelosde implementacioacuten el foco de esta guiacutea es el disentildeo arquitectoacutenico REST (Representational StateTransfer) Las APIs que siguen este modelo de implementacioacuten se llaman RESTful APIs
Una caracteriacutestica relevante de este modelo es el uso de estaacutendares abiertos como HTTPHTTPSlo cual no vincula las implementaciones de la API en el servidor o de las aplicaciones cliente conninguna implementacioacuten concreta es decir ambos componentes se pueden implementar usandolenguajes de programacioacuten diferentes siempre que puedan formular solicitudes y entenderrespuestas usando el protocolo HTTP
Una API REST se puede implementar utilizando cualquier lenguaje de programacioacuten siendo losmaacutes habituales Java NET Python PHP Ruby o el maacutes reciente Nodejs En el apartado dereferencias de esta guiacutea se detalla una serie de herramientas de uso habitual para laimplementacioacuten y documentacioacuten de APIs
Las API REST se disentildean para exponer e interactuar con recursos que son objetos datos o serviciosa los que puede acceder un cliente Conceptualmente un recurso no debe asociarse con unaestructura fiacutesica de datos dado que podriacutea derivar de consultas internas a varias tablas de unabase de datos relacional y presentarse al cliente como una uacutenica entidad
API REST por tanto es una interfaz entre servidores y clientes para intercambiar representacionesde datos en la Web en diferentes formatos sobre todo JSON y XML
El uso del protocolo HTTP como meacutetodo de acceso y de URIs para identificar uniacutevocamenterecursos de datos de forma individual aportan una separacioacuten fundamental entre peticiones yrespuestas de datos logrando implementaciones de servicios y aplicaciones maacutes eficientes
02iquestCoacutemo se implementa una API
6
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Una ventaja inherente al uso de estaacutendares de la Web para el disentildeo de APIs es laposibilidad de utilizar enlaces a recursos adicionales como complemento a la salida dedatos como por ejemplo un enlace a un diccionario de datos o cualquier tipo dedocumento hipermedia relacionado con la salida de la API
code 200 text OK data
update_time 2013-01-01T030002Z route_id 52 route_name Lexington South route_description Lexington corridor south of Market route_type 3
links [
href httpsdatamycityexamplecomtransportapiv2routes52 rel self type applicationjsonmethod GET
href httpsdatamycityexamplecomtransportapiv2routesrel collectiontype applicationjson
method GET
href httpsdatamycityexamplecomtransportapiv2schedules52 rel describedbytype applicationjson
method GETrdquo
href httpsdatamycityexamplecomtransportapiv2maps52 rel describedby type applicationjson method GET
]
02
Ejemplo de peticioacuten de informacioacuten a una API sobre rutas de bus en una ciudad
GET httpsdatamycityexamplecomtransportapiv2routes
Ejemplo de respuesta a la peticioacuten anterior que utiliza coacutedigos de respuesta estaacutendar HTTP y devuelve ademaacutes de datos concretos sobre la ruta enlaces a otros recursos vinculados
7
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
02La comunicacioacuten entre servidor y clientes sobre la Web se realiza mediante el intercambiode mensajes HTTP en un contexto seguro de interaccioacuten Los mensajes son de dos tipospeticiones enviadas por el cliente al servidor para solicitar el inicio de alguna accioacuten parainteractuar con recursos de informacioacuten y respuestas que constituyen la materializacioacuten dela accioacuten solicitada
Cada peticioacuten contiene toda la informacioacuten necesaria para ejecutar la accioacuten requerida loque implica que toda la interaccioacuten se realiza en un uacutenico ciclo y no es necesario recordarninguacuten estado previo para satisfacerla Esta es una caracteriacutestica importante de laarquitectura REST Implica que el contenido solicitado por el cliente no queda almacenadoen el servidor entre solicitudes sino que la informacioacuten sobre el estado de la sesioacuten lamaneja el cliente
Las acciones u operaciones tambieacuten llamadas meacutetodos se especifican mediante el uso delos denominados verbos HTTP
En una peticioacuten cada meacutetodo tiene encomendada una misioacuten Cualquier sistema queexponga una API REST dispone de los siguientes meacutetodos
bull GET recupera una representacioacuten de un recurso de datos
bull HEAD recupera la cabecera de una respuesta
bull POST crea un nuevo recurso de datos
bull PUT actualiza un recurso existente o lo crea si no existe previamente
bull PATCH realiza una actualizacioacuten parcial de un recurso
bull DELETE elimina un recurso de datos existente
bull OPTIONS recupera las opciones de comunicacioacuten para el recurso solicitado
Los meacutetodos expuestos pueden incluir un cuerpo de mensaje para especificar detalles sobrela peticioacuten
En el contexto de los Datos Abiertos no es habitual disponer de los meacutetodos PUT PATCH oDELETE Normalmente se dispone de los meacutetodos GET HEAD o POST usando GET como laoperacioacuten comuacuten para el acceso y descarga de recursos de datos
iquestCoacutemo funciona una API
8
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Siempre que sea posible Los meacutetodos habituales para consumir datos abiertos son ladisponibilidad de archivos descargables y el acceso a datos de forma automatizada a traveacutesde APIs Ambos meacutetodos no son excluyentes
Desde el punto de vista de la publicacioacuten de datos habilitar APIs de acceso estables y biendocumentadas requieren un mayor esfuerzo inicial no obstante a medio plazo resultabeneficioso para el publicador que aumenta las capacidades de innovacioacuten permitiendo alos desarrolladores crear nuevas aplicaciones y servicios explotando datos reutilizables
Una buena estrategia de apertura de datos tendraacute disponible la uacuteltima versioacuten de los datos atraveacutes de APIs y tambieacuten los histoacutericos generados con anterioridad adecuadamenteversionados en ficheros estaacuteticos descargables
La disponibilidad de APIs es el mecanismo maacutes eficiente para consumir datos con altafrecuencia de actualizacioacuten es decir cercanos al tiempo real de tal forma que los sistemasque producen los datos puedan hacerlos disponibles de forma automaacutetica
Es aconsejable disponer APIs si los conjuntos de datos son grandes de alta frecuencia deactualizacioacuten o incluso de alta complejidad la opcioacuten de implementar una API es la maacutesadecuada ya que seraacute posible para el disentildeador modelar las representaciones de los datosadecuadamente y permitir aplicar determinadas operaciones de filtrado y seleccioacuten
02iquestCuaacutendo es recomendable habilitar APIs para el acceso a Datos Abiertos
9
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
02bull Datos Abiertos de Zaragoza httpswwwzaragozaessedeportaldatos-abiertosapi
bull Dades Obertes Manlleu httpsdadesobertesdibacatdades-obertesdocumentacio-tecnicaapi
bull Aemet OpenData API httpsopendataaemetes
bull Cataacutelogo de APIs Abiertas ISTAC httpswww3gobiernodecanariasorgaplicacionesappsistacapi
bull EMT mobilitylabs httpsmobilitylabsemtmadridesesportalopendata
Existen Iniciativas de Datos Abiertos de la Administracioacuten Puacuteblica en Espantildea que incorporan ladisponibilidad de APIs en sus estrategias de apertura de datos Entre otras cabe mencionar
iquestDoacutende se estaacuten publicando APIs
Un espacio de referencia para observar laevolucioacuten de la denominada ldquoeconomiacutea delas APIsrdquo es el repositorio del sitio webespecializado ProgrammableWeb
Ademaacutes de ser un importante centro derecursos para el desarrollo de APIs publicauno de los directorios maacutes completos Entreotras categoriacuteas detalla un nuacutemerorelevante de APIs disponibles en el aacutembitode la Administracioacuten Puacuteblica
bull Repositorio httpswwwprogrammablewebcomcategoryallapis
bull Otros repositorios de APIs puacuteblicas se pueden encontrar en httpsapisgurubrowse-apishttpspublic-apisxyzhttpssmart-apiinfo
Algunas APIs de notable eacutexito y de usosencillo estaacuten disponibles en empresas quegestionan voluacutemenes ingentes deinformacioacuten Amazon Google Maps Twittero Paypal entre otras De forma generalestaacuten muy bien documentadas y son unreferente importante para comprender elalcance de una buena documentacioacuten
Ejemplos de APIs puacuteblicas muy populares
bull API de Github httpsdevelopergithubcomv3
bull API de Google Maps httpscloudgooglecommaps-platformhl=es
bull API de Twitter httpsdevelopertwittercom
10
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
02Un enfoque importante para facilitar la interoperabilidad de sistemas de informacioacuten esoptimizar la interconexioacuten de APIs
La plataforma FIWARE se desarrolla a partir del programa europeo para el desarrollo de Internetdel Futuro con el objetivo de construir un ecosistema sostenible alrededor de estaacutendaresabiertos para acelerar el desarrollo de soluciones inteligentes para diferentes dominios
Una de las ventajas de FIWARE es la capacidad para facilitar la interaccioacuten con informacioacuten decontexto es decir datos de entorno originados en diferentes fuentes como por ejemplo redesde sensores aplicaciones moacuteviles o todo tipo de sistemas de informacioacuten y redes sociales paragenerar acciones propias del entorno en el que se implementa una solucioacuten
Para gestionar informacioacuten de contexto FIWARE cuenta con un componente central llamadoContext Broker a traveacutes del cual se interactuacutea con otras plataformas o aplicaciones utilizando laespecificacioacuten NGSI
La concepcioacuten de API restful NGSI como un estaacutendar abierto ofrece a los programadores lacapacidad de integrar las aplicaciones que desarrollan a traveacutes de diferentes plataformasPowered by FIWARErdquo y un marco estable de desarrollo permitiendo enriquecer la funcionalidadde cualquier solucioacuten Smart resolviendo la integracioacuten a traveacutes del componente FIWARE ContextBroker Esta integracioacuten se simplifica ya que todos los componentes cumplen con la interfazestaacutendar FIWARE NGSI a la vez facilita una evolucioacuten de las soluciones en funcioacuten de lasdiferentes necesidades de negocio que se puedan plantear
Otro de los elementos esenciales que aporta el ecosistema FIWARE es un conjunto de modelos de datos que se han armonizado para permitir la portabilidad de datos para diferentes aplicaciones Entre otros hay modelos de datos disponibles para los siguientes dominios de informacioacuten Smart-Sensoring SmartAgrifood SmartCities SmartEnergy SmartEnvironment SmartWater Cross sector (que agrupa modelos de datos que aplican en varios dominios entre otros weather) SmartManufacturing SmartRobotics y Smart Destinations (turismo)
Ecosistema FIWARE
11
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
La unidad didaacutectica rdquoBuenas praacutecticas en el disentildeo de APIs y Linked Datardquo del cataacutelogo demateriales formativos de la Iniciativa Aporta profundiza y amplia el contenido en esta guiacutea Sulectura permitiraacute
bull Entender los principios generales de las APIs web basadas en protocolo HTML
bull Ser capaz de realizar un disentildeo a alto nivel del esquema de direcciones (URLs) yoperaciones (meacutetodos) de una API REST para acceso a datos gubernamentales teniendo encuenta las recomendaciones teacutecnicas ya existentes
bull Comprender queacute son los formatos semaacutenticos y la importancia de los datos enlazadoscomo solucioacuten teacutecnica al movimiento por los datos abiertos
bull Entender la evolucioacuten y relacioacuten entre los conceptos de datos abiertos (Open Data) y datosenlazados (Linked Data)
bull Conocer los proyectos institucionales maacutes relevantes que apuestan por el uso de datosenlazados y web semaacutentica para ofrecer datos abiertos gubernamentales
bull Entender los principios generales y tecnoloacutegicos de la web semaacutentica y su diferencia conformatos
bull Entender coacutemo funcionan las consultas semaacutenticas mediante el lenguaje SPARQL
iquestDoacutende ampliar informacioacuten sobre APIs 02
12
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Pautas de disentildeo e implementacioacuten de APIs
En el siguiente apartado de esta guiacutea se recogen una serie de pautas sobre el disentildeo eimplementacioacuten de APIs
P1 - Planificar el ciclo de vida
P2 - Usar URIs para recursos
P3 ndash Gestioacuten de Resultados
P4 - Especificacioacuten OpenApi(OAS)
P5 - Recomendaciones sobre seguridad en las APIs
P6 - Desacoplar servicios de Datos
P7 - Facilitar el acceso a Datos en tiempo real
P8 - Formato de entrega deDatos
P9 - Usar cabeceras HTTP
P10 - Definir interpretaciones comprensibles de coacutedigos
P11 - Incorporar una documentacioacuten completa
P12 - Evitar rupturas de servicio
P13 - Evitar la degradacioacuten del rendimiento del servidor
13
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03
La disponibilidad de datos a traveacutes de una API requiere una visioacuten holiacutestica y la aplicacioacuten de unmodelo de gestioacuten adecuado para maximizar el valor de la API
Entre otras cuestiones los publicadores de datos ademaacutes de garantizar el acceso a los recursosde datos disponibles y documentar las especificaciones de la API deben tener en cuentaparaacutemetros relacionados con la frecuencia de actualizacioacuten la latencia introducida en elprocesamiento de los recursos la infraestructura necesaria para su disponibilidad y la respuestade la comunidad de reutilizadores
Estos aspectos y otros que se iraacuten desgranando en esta guiacutea deben ser tenidos en cuenta en lasdiferentes etapas del ciclo de vida de una API De manera orientativa se indican loscomponentes que lo configuran
De forma resumida y no exhaustiva estas etapas conllevan la ejecucioacuten de las siguientes tareas
bull Disentildeo definicioacuten de requisitos de modelado de recursos seguridad infraestructuraniveles de calidad de servicio versionado y documentacioacuten
bull Implementacioacuten preparacioacuten de backend y de la capa de administracioacuten para implementarpoliacuteticas de seguridad operaciones paraacutemetros y publicacioacuten en la Web
bull Despliegue establecimiento de la puerta de enlace para atender peticiones
bull Administracioacuten parametrizacioacuten y gestioacuten de los acuerdos de nivel de servicio
bull Descubrimiento publicacioacuten de la API con sus especificaciones y documentacioacuten encataacutelogos puacuteblicos de acceso a APIs Implicacioacuten de la comunidad de reutilizadores
bull Monitorizacioacuten evaluacioacuten y meacutetricas de rendimiento niveles de servicio y seguridad
P1 - Planificar el ciclo
de vida
Disentildeo
Implementacioacuten
Despliegue
Administracioacuten
Descubrimiento
Monitorizacioacuten
14
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Las API REST gestionan y exponen recursos de informacioacuten direccionables por medio deIdentificadores de Recursos Uniformes (URI) que los diferencia y permiten al acceso a cualquierade las representaciones disponibles
Es habitual confundir los conceptos de URI y URL y en muchos textos se utilizan ambos teacuterminosindistintamente pero hay una diferencia sustancial [1]
Corresponde a los disentildeadores definir las URIs que se utilizaraacuten para invocar a la API por lo quees fundamental incorporar en la etapa de disentildeo una buena estrategia de nombrado como severaacute a continuacioacuten en el apartado de pautas de esta guiacutea
Las URIs responden al siguiente patroacuten de construccioacuten
Cada elemento de la URI tiene una misioacuten y su especificacioacuten debe ser adecuada para que la URIresultante sea intuitiva y faacutecilmente comprensible para el usuario
Son elementos de la URI los siguientes
bull El esquema o protocolo de acceso normalmente ldquohttpsrdquo o rdquohttprdquo
bull La autoridad que publica la API indicada por el nombre del servidor yopcionalmente el puerto de acceso donde estaacute desplegada la API
bull La versioacuten de la API numerada secuencialmente desde la primera
bull La ruta de acceso al recurso o endpoint que se consulta y la operacioacuten que serealiza sobre el recurso
bull La consulta sobre el recurso con las opciones de filtrado que sean necesarias sonelementos opcionales de la URI
P2 - Usar URIs para
identificar recursos
URI = esquema autoridad ruta [ consulta] [rdquo fragmento]
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizado
[1] Diferencia entre URI y URL
Las URIs identifican recursos es decir indican su nombrersquo y las URLs localizan tales recursos es decir indican suubicacioacuten en la red sin embargo los localizadores tambieacuten son identificadores por lo que cada URL tambieacuten esun URI pero hay URI que no son URL Por ejemplo el nombre de una persona es un identificador pero noinforma sobre su localizacioacuten en cambio una direccioacuten postal es un localizador y ademaacutes es un identificador deuna localizacioacuten fiacutesica y podriacutea ser indirectamente el identificador de una persona si fuese la uacutenica persona quehabita en esa direccioacuten postal
15
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Recomendaciones para el disentildeo de URIs
Un buen disentildeo de URIs debe partir de una adecuada estrategia de nombrado de recursos LasAPI REST pueden manejar diferentes tipos de recursos
bull Documentos instancias o representaciones individuales de recursos
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratosid-contrato
bull Colecciones para referir conjuntos de recursos individuales
bull Por ejemplo httpsdatosejemplocomv1licitacionescontratos
bull Almacenes o lsquostoresrsquo que son repositorios de recursos gestionados por clientes
bull Por ejemplo httpsapimusicacomV1usuarioidplaylist
bull Controladores de recursos para definir procesos al margen de los meacutetodos estaacutendar
bull Por ejemplo httpsapimusicacomV1usuarioidplaylistplay
Esta guiacutea orientada a la publicacioacuten de Datos Abiertos se centra en la publicacioacuten de recursosindividuales o colecciones
A continuacioacuten se detallan una serie de recomendaciones a tener en cuenta para el disentildeo deURIs
bull Sobre el uso del lenguaje
bull Usar teacuterminos sencillos intuitivos y coherentes
bull Los teacuterminos que se utilicen deben ser suficientemente auto-explicativos
bull Evitar la ambiguumledad para la denominacioacuten de recursos en las URIs
bull Usar teacuterminos que no requieran un conocimiento especifico del contexto
bull Se deben evitar nombres que puedan entrar en conflicto con palabras clave utilizadas enlos lenguajes de programacioacuten
bull Coherencia con el uso del plural o singular Se pueden expresar los teacuterminos en singular oplural pero tomada la decisioacuten debe ser estricta su aplicacioacuten No obstante el uso delplural es la pauta maacutes generalizada
16
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03bull Usar el separador ldquordquo para indicar relaciones de jerarquiacutea entre recursos Por ejemplo
httpsdatosejemplocomv1licitaciones
httpsdatosejemplocomv1licitacionescontratos
httpsdatosejemplocomv1licitacionescontratosmenores
httpsdatosejemplocomv1licitacionescontratosmenoresservicios
bull No incluir el separador ldquordquo como caraacutecter final de la URI dado que no aporta valor semaacutenticoy puede generar confusioacuten
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratos
Ambas formulaciones son vaacutelidas dado que un navegador podraacute interpretar cualquiera de lasdos pero la primera es mejor que la segunda
bull Usar el caraacutecter ldquo-rdquo para mejorar la legibilidad de la URI
Correcto httpsdatosejemplocomv1licitacionescontratosid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontratosidcontrato
bull No usar el caraacutecter ldquo_rdquo
Correcto httpsdatosejemplocomv1licitacionescontrato-menorid-contrato
Incorrecto httpsdatosejemplocomv1licitacionescontrato_menorid_contrato
Al utilizar navegadores o editores de texto el caraacutecter subrayado rdquo_rdquo puede quedar oculto ya queestas herramientas subrayan los identificadores para proporcionar una sentildeal visual de que sepuede hacer clic
17
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03bull Usar minuacutesculas para expresar los teacuterminos de la URI
(1) httpsdatosejemplocomv1licitacionescontratos
(2) httpsDATOSEJEMPLOCOMv1licitacionescontratos
(3) httpsdatosejemplocomv1LicitacionesContratos
La forma normalizada es utilizar letras minuacutesculas La especificacioacuten RFC 3986 define que solo elesquema y la autoridad (host) de las URIs no son sensibles a mayuacutesculas y minuacutesculas Seguacutenesto Las URIS de los ejemplos 1 y 2 son iguales pero no la 1 y la 3
bull No incluir extensiones de archivo
Correcto httpsdatosejemplocomv1licitacionescontratos
Incorrecto httpsdatosejemplocomv1licitacionescontratosxml
Incluir la extensioacuten de un archivo no antildeade ninguna ventaja e incrementa el tamantildeo de la URI Esrecomendable especificar el formato usando las cabeceras HTTP
bull No usar nombres de funciones CRUD en las URIs
Las URIs deben usarse uacutenicamente para identificar recursos y no para indicar acciones sobre ellosLas funciones Crear Leer Actualizar y Borrar conocidas por el acroacutenimo CRUD (del ingleacutes Create-Read-Update-Delete) no deben usarse en las URIs Esa misioacuten ya la realizan los meacutetodos HTTP(GET POST PUET DELETE etc)
Correcto HTTP GET httpsdatosejemplocomv1licitacionescontratos
Incorrecto HTTP GET httpsdatosejemplocomv1licitacionesobtenercontratos
El primer ejemplo permite obtener la coleccioacuten de contratos ya que se usa el meacutetodo GET y sumisioacuten es recuperar un recurso en este caso una coleccioacuten
18
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P3 ndash Gestioacuten de Resultados
Uno de los usos maacutes probables de una API es el acceso a porciones concretas de datos en base alas especificaciones que determina el usuario Para ello las API REST permiten definir dichoscriterios en la parte de la URI destinada a la consulta habilitando asiacute funcionalidades de filtradoordenacioacuten y paginacioacuten para recuperar exclusivamente los datos necesarios
bull Filtrado devuelve el resultado de la evaluacioacuten de una expresioacuten loacutegica compuesta portres componentes propiedad operador loacutegico y valor que pueden ser concatenadosutilizando el caraacutecter lsquoamprsquo aportando flexibilidad a la consulta La sintaxis sigue lasiguiente estructura
[campo][operador][valor]
Son operadores habituales igual (= o lsquoeqrsquo) mayor o igual (gt= o lsquogtersquo) menor o igual (lt= orsquoltersquo) contiene (~) para campos de texto Otros operadores que tambieacuten pueden seraplicables son [exists] [regex] [before] y [after] El operador de concatenacioacuten lsquoamprsquo esevaluado como un OR para los valores de un mismo nombre de atributo y AND entreatributos distintos
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019
El ejemplo anterior estaacute recuperando de la coleccioacuten de contratos los registros de 2019correspondientes a contratos finalizados Existen lenguajes de consultas como FIQL o RSQL(evolucioacuten del anterior) que facilitan el filtrado parametrizado de invocaciones a APIRESTful
bull Ordenacioacuten devuelve las peticiones ordenadas seguacuten un determinado criterio aplicadosobre propiedades del recurso Se expresa mediante paraacutemetros lsquosortrsquo lsquosort_byrsquo ulsquoorderrsquo que admiten modificadores para indicar el sentido del orden lsquoascendentersquo olsquodescendentersquo
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosestado=finalizadoampannio=2019ampsort=fecha-adjudicacion
Al ejemplo anterior se antildeade el requisito de ordenacioacuten por fecha de adjudicacioacuten
19
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03bull Paginacioacuten permite acotar los resultados devueltos por una peticioacuten Se pueden utilizar
diferentes paraacutemetros
o paginacioacuten con lsquooffsetrsquo
o Paginacioacuten basada en tiempo con lsquolimitrsquo
o Paginacioacuten basada en cursor o identificador especiacutefico de registro
Por ejemplo
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25ampestado=finalizado
El ejemplo anterior estaacute devolviendo de la coleccioacuten de contratos los registros entre el51 y el 75 El siguiente ejemplo estaacute devolviendo registro especiacutefico y situando unpuntero al siguiente registro sobre el que se situacutea el comienzo de la consulta obtener lasiguiente paacutegina de resultados
httpsdatosejemplocomv1licitacionescontratoscursor=1234567
Ademaacutes es posible implementar mecanismos de control de paginacioacuten utilizandoparaacutemetros como los que se indican a continuacioacuten
o Utilizando un identificador de paacutegina especiacutefico usando lsquopaginationkeyrsquo
o el nuacutemero de orden de pagina que contiene resultados de una consulta usando lsquopagersquo
o el nuacutemero de elementos que debe contener una pagina de respuesta usando lsquopageSizersquo
o Otros indicadores de paginacioacuten para controlar movimientos entre paacuteginas usandolsquofirsLinkrsquo lastLinkrsquo nextLink previousLink selfLink que permiten desplazamientos aprimera ultima siguiente previa o paacutegina actual
Ejemplos
httpsdatosejemplocomv1licitacionescontratosoffset=50amplimit=25amppaginationKey=xyz
El ejemplo estaacute devolviendo contenido en funcioacuten de una paacutegina concreta que posee undeterminado identificador de paacutegina
httpsdatosejemplocomv1licitacionescontratospageSize=2amppage=3
El ejemplo estaacute devolviendo contenido de la tercera paacutegina de resultados con doselementos por paacutegina
20
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03
Para comprender la motivacioacuten principal de la existencia de un estaacutendar abierto para APIs esimportante entender el punto de vista del desarrollador una parte importante de su actividadse consume en la integracioacuten de servicios de informacioacuten provistos por muacuteltiples APIs sujetasen numerosas ocasiones a especificaciones dispares lo que obliga a crear adaptacionespersonalizadas a las condiciones de cada servicio con el consiguiente coste y potencialineficiencia
La especificacioacuten OpenAPI (OAS) define una descripcioacuten estaacutendar de interfaz independientedel lenguaje de programacioacuten para las API REST que permite que tanto personas comomaacutequinas descubran comprendan y usen las capacidades de un servicio
OpenAPI es una evolucioacuten abierta del proyecto Swagger que promueve la interoperacioacuten desistemas mediante interfaces claras y perdurables en el tiempo Actualmente OpenAPIimplementa la versioacuten 30
OpenAPI permite bajo un mismo marco de trabajo
Disentildear y documentar una API Rest
Cumplir y hacer compatible la API generada con estaacutendares
Generar interfaces de desarrollo (SDKs) con el nivel de abstraccioacuten miacutenimosuficiente para que terceros puedan comunicarse con la API garantizando sufuncionamiento en diferentes versiones de un mismo lenguaje
Personalizar y adaptar la interfaz a necesidades especiacuteficas
Ejecucioacuten y pruebas de la API
Meacutetricas de uso y analiacuteticas
Una caracteriacutestica esencial de OpenAPI es que a medida que se actualiza el coacutedigo de la API lohace la documentacioacuten de los meacutetodos paraacutemetros y modelos de datos permitiendo que laAPI y su documentacioacuten esteacuten siempre sincronizadas
Uno de los posibles casos de uso de OpenAPI es la aplicacioacuten de esta especificacioacuten acualquier API existente obteniendo con ello una API documentada de acuerdo al estaacutendar y lageneracioacuten de SDKs para cliente
Ejemplo de uso de la especificacioacuten OpenAPI en el portal de Datos Abiertos de la Unioacuten Europea
httpsappswaggerhubcomapisEU-Open-Data-Portaleu-open_data_portal080
P4 - Especificacioacuten
OpenApi (OAS)
21
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03A modo de ejemplo se detalla de forma muy resumida algunos pasos constructivos que ilustrancoacutemo se crea una operacioacuten utilizando Swagger
Despueacutes de ajustar determinados valores que constituyen la URI del acceso base a la API comoes el nombre de host y el numero de puerto se ajustan los elementos que definan operacionessobre recursos Para cada operacioacuten seraacute necesario
bull Asignar un nombre al controlador que se encargaraacute de procesar la peticioacuten
bull Asignar el meacutetodo a la operacioacuten que se implementa al invocar este controlador Porejemplo GET
bull Definir el conjunto de paraacutemetros de entrada Por ejemplo coordenadas de un punto enforma de Latitud Longitud para que la peticioacuten devuelva paradas de bus en el entorno de1 km a la redonda
bull Definir la forma que tendraacute la respuesta es decir se devolveraacute un coacutedigo http 200 y laestructura de los datos devueltos denominada carga uacutetil en el formato de salida previstopor ejemplo en formato JSON
bull Por uacuteltimo se ajustaraacuten otros valores de respuesta para indicar posibles errores y evitarmensajes por defecto
El resultado final de esteproceso seraacute similar al que semuestra en la siguiente imagenen la que se observa ladocumentacioacuten de la EmpresaMunicipal de Transportes(EMT) de Madrid
La especificacioacuten completa seencuentra disponible en
httpsapidocsemtmadrides
22
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P5 - Recomendaciones
sobre seguridad en las APIsLa seguridad de las API y la forma en la que eacutesta debe implementarse depende en ciertamedida del tipo de datos que se transfiere y de la sensibilidad de los mismos Es razonablepensar que el nivel de proteccioacuten y autenticacioacuten de usuarios necesario para una APItransaccional (de lectura escritura) debe ser mayor que el requerido para una API desolo lectura
En el contexto de los Datos Abiertos el foco estaacute en la lectura de datos y en cierta medidael meacutetodo HTTP que se utiliza fundamentalmente es GET No obstante hay una serie depautas que de forma general deben tenerse en cuenta a la hora de disponer recursos atraveacutes de la Web para su consumo por parte de terceros
Como se ha comentado las API REST exponen recursos que son accedidos y manipulados atraveacutes del protocolo HTTP y cuyos intercambios de informacioacuten pueden ser cifrados de talforma que mantengan privadas las interconexiones entre sistemas
De forma paralela es fundamental preservar la integridad de las APIs de usos abusivos omalintencionados de los servicios expuestos
Por otro lado hay que valorar el nivel de autenticacioacuten requerido a los usuarios de la APIcon el objetivo de mantener un equilibrio adecuado entre seguridad y maximizacioacuten del usode la API
Antes de abordar la descripcioacuten de posibles formas de interaccioacuten es necesario recomendaruna serie de pautas que siempre deben ser tenidas en cuenta independientemente del nivelde autenticacioacuten requerida a los usuarios de la API Estas recomendaciones se exponen acontinuacioacuten
23
API Security es una iniciativa que promueve la organizacioacuten de referencia a nivel internacional Open Web Application Security Project (OWASP) que se centra en la recomendacioacuten de estrategias y soluciones para entender y mitigar vulnerabilidades y riesgos de seguridad La iniciativa propone 10 directrices fundamentales para la implementacioacuten de las API
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Recomendaciones sobre el cifrado de los intercambios deinformacioacuten
Es aconsejable configurar de forma segura los servicios que reciben conexiones entrantes declientes desconocidos como es el caso de peticiones a una API Para ello es aconsejable entreotras cuestiones
1
2 3
4
Publicar servicios usando solo HTTPS (HTTP sobre TLS) De esta forma la informacioacutenviajariacutea encriptada Transport Layer Security (TLS) es un protocolo que proporcionaprivacidad entre las aplicaciones y usuarios o entre servicios de intercambio deinformacioacuten Cuando un servidor y un cliente se comunican la configuracioacuten adecuada deTLS garantiza que ninguacuten tercero pueda interferir o alterar ninguacuten mensaje
Redirigir automaacuteticamente a losusuarios que visitan la versioacuten HTTPde un servicio en la Web a laversioacuten HTTPS
Usar las uacuteltimas versiones establesde las libreriacuteas (TLS y componentessoftware desplegados para ladisponibilidad del servicio) evitandosiempre la existencia devulnerabilidades conocidas
Habilitar poliacutetica de seguridad HTTPStrict Transport Security (HSTS)paraestablecer que todo el traacutefico entrecliente y servidor debe realizarsesobre HTTPS
5 Adquirir los certificados de servidoren autoridades de certificacioacutenconfiables
24
Al margen del cifrado de datos es recomendable prestar atencioacuten al problema conocido como JSON injection que es necesario prevenir Como ya se ha sentildealado es comuacuten el uso del formato de intercambio JSON en API RESTful El problema estaacute relacionado con el potencial para la inyeccioacuten de coacutedigo malicioso JavaScript en cadenas JSON La vulnerabilidad se puede dar en dos vertientes del lado del servidor cuando los datos de un origen no confiable no son desinfectados por el servidor o del lado del cliente cuando los datos de una fuente JSON no confiable no se desinfectan y analizan directamente mediante la funcioacuten eval de JavaScript Por tanto es altamente recomendable adoptar un sanitizer como json-sanitizer de OWASP Igualmente resulta conveniente hacer comprobaciones de sistemas con pruebas de penetracioacuten especiacutefica como Freddy the Serial(isation) Killerrsquo
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Autenticacioacuten de usuarios
A continuacioacuten se describen tres enfoques de requisitos de autenticacioacuten de usuarios para lainteraccioacuten con APIs Hay otros enfoques como el uso de usuario y contrasentildea que no se estaacuteconsiderando en el detalle siguiente por ser menos eficiente Los enfoques siguientes se muestranordenados de menor a mayor nivel de seguridad
1 Sin autenticacioacuten
En el contexto de los Datos Abiertos puede serfactible no requerir ninguacuten tipo de autenticacioacuten deusuarios Este enfoque se puede usar cuando elriesgo asociado con la API es poco significativo porejemplo si solo estaacute permitido el uso del meacutetodoGET para el acceso a los datos La desventaja deeste modelo es que hace que sea difiacutecil recopilaranaacutelisis efectivos y realizar un monitoreo paradetectar actividades maliciosas
2 Autenticacioacuten por medio de claves API(API Key)
Una API Key es una cadena larga de caracteres quefunciona como una especie de contrasentildea quetiene una caducidad La autenticacioacuten medianteAPI Key requiere que la clave generada tenga queser utilizada en cada interaccioacuten entre sistemas Lapraacutectica habitual es que el desarrollador deaplicaciones obtenga una clave para su aplicacioacutendel proveedor de la API y la utilice dentro de suaplicacioacuten Para obtener la clave El desarrolladorpreviamente realiza un proceso de registro Lasclaves API son pares clave API puacuteblica eidentificador API privado utilizado para validar laprimera La caducidad de la clave determina elperiodo de tiempo consecutivo sin que el usuariotenga que volver a acreditarse
Ejemplo de uso de API del Registro delReino Unido que no requiereautenticacioacuten de usuario para suinvocacioacuten
httpswwwregistersservicegovuk
Ejemplo de documentacioacuten de la API dela Empresa Municipal de Transportes(EMT) de Madrid en la que se explica elmeacutetodo de autenticacioacuten requerido
httpsapidocsemtmadridesapi-Block_1_User_identity
25
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
033 Autenticacioacuten utilizando OAuth (Open Authorization)
OAuth es un estaacutendar abierto de autorizacioacuten basado en la concesioacuten de token de accesoque se implementa usando diferentes flujos de concesioacuten de autorizacioacuten que sedesencadenan en funcioacuten de determinadas situaciones o patrones Estos patrones definenlos diferentes tipos de interaccioacuten que una aplicacioacuten cliente puede realizar para obtener untoken de acceso y por lo tanto acceder al recurso protegido de la API
Hay cuatro tipos de flujos de autorizacioacuten soportados por OAuth 20 denominados coacutedigode autorizacioacuten autorizacioacuten impliacutecita credenciales de contrasentildea del propietario delrecurso y credenciales de cliente
Los flujos de autorizacioacuten que propone OAuth 20 se plantean para proporcionar a lasorganizaciones la flexibilidad de soportar diferentes escenarios de interaccioacuten deaplicaciones de clientes por lo que es importante conocer el detalle sobre lo que ofrececada flujo de autorizacioacuten y que supone su implementacioacuten
El Coacutedigo de autorizacioacuten es el modelo maacutes utilizado y es el modelo maacutes seguro Por otrolado la autorizacioacuten impliacutecita es el flujo menos seguro y la recomendacioacuten para suimplementacioacuten estaacute ligada a la autorizacioacuten de acceso solo a informacioacuten puacuteblica y solocuando se usa el meacutetodo GET
26
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03
Recomendaciones sobre limitacioacuten de uso
Las directivas de limitacioacuten de uso se realizan mediante ajustes de la tasa de peticiones oestableciendo cuotas por peticioacuten para una clave dada donde la clave puede ser la direccioacuten IPdel cliente que realiza la peticioacuten o la clave API otorgada en el proceso de autenticacioacuten
1 2Tasa de peticiones por clave
Sirve para evitar picos de uso de laAPI limitando la tasa de peticionesa un nuacutemero especificado por unperiacuteodo de tiempo establecido Porejemplo 10 peticiones porsegundo para una misma IP
Cuota de uso por clave
En teacuterminos de volumen de llamadasyo una cuota de ancho de banda esdecir cantidad maacutexima de kilobytespermitidos durante el intervalo detiempo
Por ejemplo 10000 peticiones y40MB de datos en el periodo de 3600segundos para una misma IP
Cuando se desencadena alguna de estas directivas el autor de la llamada recibe un coacutedigo deestado de respuesta 429 Too Many Requestsrsquo
Es importante tener en cuenta que la monitorizacioacuten de las meacutetricas de servicio de la API yen particular de consultas y limitaciones es esencial para un preciso dimensionamiento estetipo de limitaciones y en general de todas las directivas de seguridad aplicadas
27
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P6 - Desacoplar servicios
de Datos
A diferencia de otras APIs de uso interno o de uso externo de propoacutesito especial parausuarios con los que se mantiene una relacioacuten contractual conocidos como partner APIs lasAPIs puacuteblicas o APIs abiertas son las que se utilizan en el contexto de los Datos Abiertosdonde cualquier usuario autenticado o no puede hacer el uso que estime oportuno tantasveces como lo requiera
Durante la etapa de disentildeo de la API es difiacutecil conocer con anticipacioacuten y suficiente detallelas necesidades de los usuarios de un servicio de datos
Es posible ademaacutes que los reutilizadores implementen soluciones exitosas que requieranun volumen significativo de datos en momentos puntuales del diacutea por lo que es importanteevitar implementar modelos de integracioacuten directos sobre los sistemas de informacioacuten delas organizaciones publicadoras En cualquier caso a la hora de implementar una API elarquitecto debe tener presente el grado de exposicioacuten de sus sistemas a los usuarios de laAPI
Es recomendable por tanto desacoplar accesos a datos puacuteblicos y privados para evitar queel impacto del consumo externo de datos tenga repercusioacuten sobre las operaciones internasde la organizacioacuten sobre los mismos datos
Este modelo de implementacioacuten permite ademaacutes implementar mejoras especificascentradas exclusivamente en la oferta de datos
En este sentido es fundamental habilitar un canal de comunicacioacuten con el sectorreutilizador para identificar patrones de consumo y casos de uso implementados con elobjetivo de anticipar potenciales riesgos derivados de sobrecarga o uso inadecuado de laAPI
28
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P7 - Facilitar el acceso a
Datos en tiempo real
Los datos en tiempo real o cercanos al tiempo real tambieacuten denominados datos sensiblesal tiempo son los que estaacuten disponibles para su reutilizacioacuten transcurridos normalmentedel orden de milisegundos o unos pocos segundos desde su creacioacuten La disponibilidad deeste tipo de datos es fundamental para impulsar el desarrollo de aplicaciones y servicios entiempo real
Hay dos enfoques fundamentales que el publicador debe tener en cuenta sobre la forma enque los usuarios necesitan consumir los datos en tiempo real publicados viacutea API
1 La necesidad de la ultima versioacuten deun determinado dato que se actualizaperioacutedicamente por ejemplo el tiempoestimado de llegada de un bus urbano auna parada
2 La necesidad de acceder de formapermanente a un flujo de datos porejemplo los datos de consumo eleacutectricode una determinada instalacioacuten
En el primer caso denominado pooling el dato se consume a partir de peticionespuntuales a demanda de los reutilizadores de forma infrecuente con el objetivo de obtenerel dato maacutes reciente disponible
En el segundo caso conocido como streaming se requiere una implementacioacuten detransmisioacuten continua de datos de tal forma que las aplicaciones cliente que desarrollan losreutilizadores reciban actualizaciones automaacuteticas del servidor
En cierto modo el streaming supone invertir la naturaleza conversacional del modelo RESTdonde se desencadena una respuesta a partir de una peticioacuten puntual como es el caso depooling cuyo requisito es mantener una frecuencia optima de refresco del dato En unescenario de streaming no hay una conversacioacuten propiamente dicha y lo que el protocolonecesita soportar es un meacutetodo para mantener el estado de una conexioacuten abiertadurante periodos largos de tiempo a peticioacuten de varios clientes que pueden hacer lamisma solicitud y luego enviar la misma informacioacuten de respuesta de forma continua yglobalmente a dicho grupo de usuarios
Por esta razoacuten para implementar un servicio de streaming API se deben tener en cuentaotro tipo de modelos que se engloban en las arquitecturas basadas en eventos
29
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P8 - Especificar el formato de
entrega de Datos usando las cabeceras HTTP
Como se ha comentado con anterioridad los recursos pueden tener muacuteltiplesrepresentaciones de los datos en funcioacuten de las expectativas de los clientes La solicitud deuna determinada representacioacuten por un cliente se denomina negociacioacuten de contenido
De forma predeterminada es recomendable devolver contenido usando JSON o XML
La ventaja de usar JSON es que es una representacioacuten adecuada para una raacutepidaserializacioacuten y deserializacioacuten de objetos de datos minimizando la transferencia de datosrequerida al tiempo que ofrece un mejor soporte que XML para representar estructuras dedatos jeraacuterquicas
Ademaacutes es preferible que las respuestas de datos se estructuren como objetos JSON y nocomo arrays (los objetos JSON pueden contener arrays JSON) dado que los arrays puedenlimitar la capacidad de incluir metadatos sobre la respuesta o antildeadir nuevas claves y valoresen el futuro
La forma de seleccionar la representacioacuten para una respuesta es ajustando las cabeceras depeticioacuten y respuesta HTTP de servidor y cliente de la forma adecuada De esta manera laAPI responde en el formato de datos que el cliente necesita y las aplicaciones clienteinterpretan la salida correctamente
bull Las representaciones de los recursos se especifican usando paraacutemetros para indicar eltipo de medios o tipo MIME Por ejemplo se usaraacuten los siguientes tipos paraespecificar los formatos maacutes habituales JSON (applicationjson) XM (applicationxml)o CSV (textcsv)
bull Del lado del servidor se utiliza el paraacutemetro Content-Type para determinar larepresentacioacuten de la respuesta
bull Del lado del cliente para determinar el tipo de representacioacuten que se requiere seutiliza el paraacutemetro Accept
bull Del lado del cliente tambieacuten es posible especificar otros elementos esencialesrelacionados con la codificacioacuten de la respuesta Entre otros el juego de caracteresAccept-charset el tipo de codificacioacuten Accept-encoding o el idioma esperadoAccept-language
Si en la cabecera de peticioacuten del cliente no se especifica el paraacutemetro Accept el servidorpuede responder con un tipo de representacioacuten preconfigurado por defecto
30
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Para ajustar con mayor precisioacuten aspectos relacionados con la negociacioacuten de contenido esposible expresar el nivel de preferencia entre diferentes opciones utilizando el modificadorlsquoqrsquo que toma valores entre 0 y 1 en la peticioacuten como se observa en el siguiente ejemplo
Para establecer JSON como formatopreferente de intercambio la interaccioacutenentre cliente y el servidor de la API es lasiguiente el cliente incluye en el cuerpo dela peticioacuten que realiza a la API diferentesparaacutemetros que personalizan la peticioacuten
GEThttpsdatosejemplocomv1licitacionescontratos
Accept applicationjson q=10applicationxml q=08textcsv q=02
Accept-Language es q=10en q=07
hellip
En el ejemplo anterior se solicita los recursos completos de la coleccioacuten de contratos y seestaacute utilizando el modificador lsquoqrsquo para determinar la preferencia de un formato y de unidioma respecto a otros La cabecera puede contener otros elementos
Por su parte el servidor entre otrametainformacioacuten indica el formato dedatos y la codificacioacuten que utiliza pararesponder a la peticioacuten
HTTP11 200 OKContent-type applicationjson charset=utf-8
Si el servidor no puede responder con la representacioacuten solicitada responderaacute con el coacutedigode estado HTTP 406 (No aceptable) que indica que el recurso solicitado no tiene unarepresentacioacuten que sea aceptable para el cliente
31
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P9 - Usar cabeceras HTTP
para el intercambio de informacioacuten
Como se ha visto en la pauta anterior las cabeceras HTTP son el medio fundamental paraestablecer una adecuada negociacioacuten de contenido pero ademaacutes tiene otras funcionesrelevantes para enviar informacioacuten adicional en el cuerpo de una peticioacuten o respuesta
Las cabeceras tienen la forma de pares clave-valor y estaacuten formadas por su nombre (nosensible a las mayuacutesculas) seguido de dos puntos y su valor (sin saltos de liacutenea)
El listado de elementos de cabecera es extenso e incluso personalizable Para mayorinformacioacuten sobre la descripcioacuten de cada uno es recomendable consultarhttpswwww3orgProtocolsrfc2616rfc2616-sec14html
En este ejemplo se observa una cabecera de contexto de respuesta que indica lalista de meacutetodos de peticiones aceptadas por un servidor Esta cabecera la enviacutea elservidor si eacuteste responde con un coacutedigo de estado 405 (Method Not Allowed)
Sintaxis Allow lthttp-methodsgtEjemplo de uso Allow GET HEAD
Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos
1 2
3
Cabecera de consulta Cabeceras que contienen maacutes informacioacuten sobre el recurso que se solicita Por ejemploldquoAcceptrdquo ldquoAccept-charsetrdquo etc
Cabecera general Cabeceras que se aplican tanto a las peticiones como a las respuestas pero sin relacioacuten con los datos que finalmente se transmiten en el cuerpo Por ejemplo ldquoConnectionrdquo ldquoCache-controlrdquo etc
Cabecera de respuesta Cabeceras que contienen maacutes informacioacuten sobre el contenido como su origen o el servidor (nombre versioacuten etc) Por ejemplo ldquoContent-lengthrdquo ldquoContent-encodingrdquo etc
4 Cabecera de entidad Cabeceras que contienen maacutes informacioacuten sobre el cuerpo de los recursos como el tamantildeo del contenido o su tipo MIME Por ejemplo rdquoContent-typerdquo rdquoContent-Languagerdquo etc
32
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P10 - Definir interpretaciones
comprensibles de coacutedigos de estado
Los coacutedigos de estado devueltos por el protocolo HTTP constituyen una informacioacuten esencialpara el desarrollador dado que sirven para distinguir entre respuestas satisfactorias einsatisfactorias a las invocaciones realizadas a la API
Por lo tanto las respuestas derivadas de las peticiones que realizan los clientes de la APIdeben ser informativas comprensibles por las personas y legibles por las maacutequinas
Es importante utilizar los coacutedigos de estado del estaacutendar HTTP en la implementacioacuten de lagestioacuten de respuesta de la API ya que ademaacutes son reconocidos por los marcos de desarrollode aplicaciones habituales
Los valores de los coacutedigos de estado se agrupan en torno a cinco categoriacuteas principales deinformacioacuten A continuacioacuten se reproducen los maacutes habituales y su interpretacioacuten
1xx InformativoSolicitud recibida el proceso de respuesta estaacute en marcha
2xx EacutexitoLa peticioacuten del cliente se ha recibido entendido y aceptado con eacutexito
3xx RedireccioacutenSe deben tomar medidas adicionales para completar la solicitud
4xx Error del clienteLa solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx Error del servidorEl servidor no pudo resolver una solicitud aparentemente vaacutelida
33
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Cuando ocurre un error el cuerpo de la respuesta debe contener al menos los siguientes elementos
Coacutedigo de estado estaacutendar HTTP
Un coacutedigo de error especiacutefico de la API que serviraacute al cliente parareaccionar apropiadamente ante el error y al equipo de soporte de la APIpara identificar su origen De esta forma cuando el cliente informe sobre elerror al equipo de soporte usaraacute este coacutedigo especiacutefico y el equipo desoporte podraacute trazar el problema y determinar exactamente queacute salioacute mal yquieacuten debe solucionarlo
Un mensaje de error legible por las personas informativo y uacutetil para elcliente de la API sin ofrecer demasiados detalles teacutecnicos Es importanteevitar revelar en la respuesta informacioacuten del sistema por ejemploreferencias a componentes internos del sistema de informacioacuten ya queesto podriacutea estar informando sobre posibles vulnerabilidades
Enlaces a detalles que complementen el mensaje y ayuden al cliente aencontrar maacutes informacioacuten
Ejemplo de respuesta de manejo de errores devuelto por una API ante una determinadapeticioacuten
Code400errorCode12345developerMessageDescripcioacuten detallada y simple del problema para orientar a
los desarrolladores sobre coacutemo resolver el problema (por ejemplo peticioacutenincorrecta falta un campo o el valor incluido no es vaacutelidouserMessageMensaje que puede transmitirse a los usuarios finales si fuese
necesariomoreInfordquohttpsdatosejemplocomv1developerpathtohelpfor12345
34
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P11 - Incorporar una
documentacioacuten completa
Los principales usuarios de las APIs son desarrolladores de aplicaciones y servicios y ladocumentacioacuten de la API es el primer punto de contacto para conocer la calidad y utilidadde la misma Si la documentacioacuten de la API estaacute completa actualizada y resulta faacutecil deentender favoreceraacute un uso maacutes eficiente
El contenido de la documentacioacuten debe reflejar inequiacutevocamente coacutemo se realizan llamadasa la API cuaacuteles son los paraacutemetros necesarios y cuaacutel seraacute la salida esperada Asimismo esfundamental reflejar con claridad que nuevas funcionalidades o resolucioacuten de problemasincorpora cada nueva versioacuten disponible de la API
Igualmente la documentacioacuten de la API debe detallar sin ambiguumledad queacute recursos estaraacute elusuario autorizado a utilizar y el meacutetodo de autenticacioacuten de usuario utilizado paragarantizar un acceso seguro si eacuteste es requerido
Al menos forman parte de la estructura de contenidos de la documentacioacuten de referencia dela API los siguientes epiacutegrafes
Se es requerido meacutetodo de autenticacioacuten utilizado para
autorizar el acceso y utilizacioacuten de los recursos
provistos
Listado completo de las peticiones que la API puede
manejar incluyendo el propoacutesito de cada una los
paraacutemetros permitidos y la salida esperada
Ejemplos de uso de cada una de las peticiones posibles
escritos en diferentes lenguajes de programacioacuten
preferentes por la comunidad de desarrolladores en cada
momento
Relacioacuten de versiones de la API y las caracteriacutesticas
incorporadas en cada una
1
Informacioacuten de contacto con los promotores de la API y
mecanismo de contacto para proporcionar feedback sobre
errores sugerencias o preguntas sobre cualquier
aspecto
Es recomendable acompantildear la documentacioacuten de alguacuten
mecanismo online que permita testar las peticiones y comprobar la respuesta de
la API
2 3
4 5 6
35
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03Es recomendable utilizar herramientas de edicioacuten para confeccionar la documentacioacuten de laAPI El uso de este tipo de herramientas facilita la generacioacuten de resultados como el que semuestra a continuacioacuten
En el apartado lsquoUtilidadesrsquo de esta guiacutea se detallan varias herramientas para confeccionardocumentacioacuten y realizar pruebas de peticiones a las APIs
Es relevante tener en cuenta que la calidad de la documentacioacuten de la API iraacute mejorando amedida que se incorpora el feedback de los desarrolladores de ahiacute la importancia demantener canales activos de comunicacioacuten con la comunidad reutilizadora
Ejemplo de documentacioacuten de la API de datos de calidad del aire de la organizacioacuten OpenAQ httpsdocsopenaqorg
36
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P12 - Evitar rupturas de
servicio o cambios abruptosCuando los desarrolladores implementan una aplicacioacuten o servicio utilizado la salida de unaAPI estaacuten confiando en las caracteriacutesticas declaradas en el conjunto de funcionalidades de laAPI entre otras cuestiones el esquema de datos o el formato de salida
Los cambios severos e imprevistos se deben evitar y en todo caso cualquier cambio menor omejora debe ser comunicado con antelacioacuten y en detalle de tal forma que losdesarrolladores conozcan los posibles progresos y puedan aprovecharlos en nuevasversiones de las aplicaciones y servicios que implementan
El foco en la mejora de las APIs debe estar en la incorporacioacuten de nuevas formas de invocara la API o nuevas opciones y no en modificar el funcionamiento de las existentes Losdesarrolladores que deciden ignorar esos cambios deben mantener el funcionamiento de susaplicaciones y servicios inalterado
Si en alguacuten momento es necesario plantear un cambio abrupto debido por ejemplo a uncambio en los datos de salida de tal forma que eacutesta sea incompatible con el disentildeo inicial dela API y por tanto la ruptura del coacutedigo de los usuarios la recomendacioacuten es abordar unredisentildeo integro de la API y la creacioacuten de una nueva versioacuten que utilice URIs a recursos dedatos diferentes a los que utiliza la API anterior
Es recomendable mantener las versiones previas disponibles para el uso de aquellosdesarrolladores que no se hayan adaptado a la ultima versioacuten liberada
Ejemplos de cambios abruptos en una API
Eliminar una peticioacuten
Cambiar el meacutetodo utilizado para hacer una peticioacuten
Cambiar la URI de un recurso utilizado en una peticioacuten
Agregar un paraacutemetro requerido para una peticioacuten
Cambiar el tipo de datos de un paraacutemetro
Cambiar el nombre de una clave en una repuesta del tipo clave-valor
Cambiar la estructura de una respuesta XML
Cambiar el tipo de datos de un valor en una respuesta
37
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03P13 - Evitar la degradacioacuten
del rendimiento del servidorComo se ha indicado anteriormente es difiacutecil predecir a priori el uso que tendraacute el servicio de datos a traveacutes de la API y es posible que se produzcan picos de demanda puntuales que pongan en riesgo el rendimiento de la API
A continuacioacuten se detallan dos aspectos importantes que impactan en el rendimiento de las APIs
La latencia es el tiempo que tarda una peticioacuten a la API en devolver unarespuesta Ajustar este indicador puede ser costoso por tanto es necesarioanalizar y valorar cada escenario para determinar la latencia asumible para el tipode datos que dispone la API
Hay que tener en cuenta que la latencia requerida para un servicio de datos entiempo real por ejemplo el dato de llegada de un autobuacutes a una parada requiereuna latencia mucho menor que la latencia para disponer un archivo de lospresupuestos de gasto del antildeo anterior En el primer caso es esencial plantearmejoras de este indicador
En este sentido hay que pensar en soluciones que permitan mejorar el rendimientoutilizando el mismo hardware optimizando la arquitectura de la API combinandorespuestas a consultas pesadas en datos poco frecuentes con respuestas ligerasrsquo ymaacutes frecuentes y soluciones de almacenamiento en cacheacute de solicitudes GET paraevitar trafico de red y consultas al sistema
Una praacutectica importante para mejorar el rendimiento del servidor de la API esutilizar teacutecnicas de caching El objetivo es recuperar informacioacuten una vez yreutilizar muchas veces El almacenamiento en cacheacute permite respuestas maacutesraacutepidas de la API a la vez que reduce la carga del servidor y se aplica a lainformacioacuten que se solicita con frecuencia pero que no cambia habitualmenteEs recomendable utilizar esta teacutecnica con aquellos recursos que se consumenhabitualmente y no cambian con mucha frecuencia
LATENCIA
CACHING
38
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
03De cara a optimizar el rendimiento de la API es importante valorar si se permite que los usuarios realicen peticiones de grandes voluacutemenes o si se imponen restricciones a los usuarios para hacer peticiones de datos maacutes pequentildeas
Si se considera que es razonable que los usuarios puedan hacer peticiones de grandesvoluacutemenes de datos es recomendable tener en cuenta las siguientes recomendaciones
- Estructuracioacuten de recursos considerando la segregacioacuten de algunos grupos de camposen recursos lsquohijosrsquo para facilitar el acceso a datos maacutes frecuentes
- Usar compresioacuten de archivos usando herramientas de software abierto como GZIPpara ello es necesario que los clientes indiquen en las cabeceras de peticiones queaceptaraacuten datos comprimidos
- Paginacioacuten de peticiones dividir los recursos en fragmentos manejables permite a losusuarios realizar muacuteltiples solicitudes en lugar de una sola
- Caching de archivos en formato CSV sobre periodos regulares de tiempo para evitarque los usuarios los generen dinaacutemicamente Esta solucioacuten implica sincronizaradecuadamente con los datos maestros
Es recomendable incluir un liacutemite por defecto para devolver cualquier consulta a la APIPor ejemplo 50 registros Esta limitacioacuten prevendraacute posibles saturaciones temporalesdel servidor No obstante el usuario debe tener la opcioacuten de recuperar todos losregistros o los que sean necesarios ajustando un paraacutemetro en la URI de invocacioacuten a laAPI
Esta limitacioacuten ademaacutes conlleva el beneficio de no inundar inadvertidamente al usuariocon todos los registros de un dataset cuando simplemente estaacute explorando los datos
Grandes voluacutemenes de datos
Limitacioacuten de registros
39
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
04Implementacioacuten de APIs en cataacutelogos de Datos Abiertos
Es recomendable que los cataacutelogos de Datos Abiertos describan con
precisioacuten los servicios de Datos disponibles viacutea API y que ademaacutes permitan el
acceso a los conjuntos de datos que publican mediante su uso
A continuacioacuten se detalla la forma de abordar este doble objetivo
Metadatos para describir APIs
La especificacioacuten del vocabulario para la catalogacioacuten de Datos Abiertos DCAT 20
incorpora una clase para definir propiedades uacutetiles para describir puntos de acceso
a APIs en el conjunto de metadatos de un cataacutelogo de Datos Abiertos
Aunque el uso de estos metadatos es opcional es recomendable usarlos ya que facilitan lainterpretacioacuten y el consumo de los Datos Abiertos a la vez que contribuyen a mejorarcalidad general de los metadatos de un cataacutelogo de Datos
La clase dcatDataService define una coleccioacuten de operaciones que proporcionan acceso auno o maacutes conjuntos de datos o funciones de procesamiento de datos
Las propiedades de esta clase son
ndash dcatendpointURL que se usa para indicar la localizacioacuten del servicio de datos
ndash dcatendpointDescription que permite aportar una descripcioacuten del servicioprocesable por maacutequinas siendo posible expresarla siguiendo especificacionesestaacutendares En esta descripcioacuten se pueden incluir el detalle sobre operaciones yparaacutemetros entre otra informacioacuten esencial del servicio
ndash dcatservesDataset define la coleccioacuten de datos que el servicio puede entregar
Igualmente la versioacuten del perfil de aplicacioacuten para portales de datos en Europa DCAT-AP20 se alinea con la actualizacioacuten de DCAT 20 e introduce la capacidad de compartirservicios de datos antildeadiendo esta misma clase con sus propiedades como metadatoopcional del cataacutelogo de datos
40
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
04APIs para el acceso a Datos en cataacutelogos de Datos Abiertos
Un requisito que debe satisfacer cualquier plataforma de Datos Abiertos es la disponibilidadde puntos de acceso que faciliten el consumo de los datos abiertos catalogados de formaautomaacutetica
Normalmente estos puntos de acceso implementan API Rest SPARQL EndPoints o ServiciosWeb geograacuteficos En los siguientes apartados se detallan los dos uacuteltimos
Las plataformas de Datos Abiertos maacutes comunes cuentan con APIs que facilitan la invocacioacutende consultas parametrizadas que permiten diversas operaciones de filtrado en el acceso alos datos disponibles Entre las operaciones habituales que se pueden utilizar usando la APIde un cataacutelogo de datos abiertos es posible
ndash Obtener el conjunto de recursos vinculados a un cataacutelogo de datos
ndash Obtener los metadatos vinculados a los datasets del cataacutelogo
ndash Exportar datasets aplicando diferentes filtros en formatos alternativos
ndash Agregar datasets a los ya existentes en el cataacutelogo
Ejemplo de invocacioacuten a la API de CKAN del portal de Datos Abiertos de Maacutelaga para obtener el dataset lsquoMalaga-bicirsquo en formato JSON
httpsdatosabiertosmalagaeuapi3actiondatastore_searchresource_id=3bb304f9-9de3-4bac-943e-7acce7e8e8f9
Las plataformas de Datos Abiertos maacutes comunes incorporan funcionalidades de API en susversiones estaacutendar
CKAN el DataStore de CKAN provee una interfaz para almacenar y hacer invocaciones a losdatos tabulares estructurados que alberga Cada uno de los datasets tiene un punto deacceso dentro del DataStore Soporta consultas tipo SQL
Socrata SODA API permite la exportacioacuten de datos en varios formatos (JSON XML y CSVentre otros) y la parametrizacioacuten de consultas a traveacutes de un dialecto denominado SocrataQuery Language o SoQLrdquo inspirado en el lenguaje de consulta SQL
OpenDataSoft Permite el acceso a todos los datos disponibles en la plataforma y retorna lainformacioacuten en formato JSON Esta API incorpora especificaciones para soportar serviciosweb geograacuteficos WFS y CSW que permiten la interrelacioacuten de esta plataforma con diferentesoftware GIS Soporta el dialecto ODSQL para consultas y filtrado de datos
41
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
05APIs para el acceso a Datos EnlazadosEn el contexto de los datos enlazados (Linked Data) es posible recuperar datos modeladossemaacutenticamente utilizando un punto de acceso a los mismos y un lenguaje de consultaespeciacutefico para este tipo de datos
El lenguaje de consulta sobre la Web semaacutentica y de los datos enlazados es SPARQL
Dicho lenguaje cumple un rol similar a los lenguajes de consulta SQL en el contexto de lasbases de datos relacionales aportando una capa que permite consultar datos que estaacuten enRDF RDFs y otros estaacutendares de la Web semaacutentica
SPARQL estaacute soportado por la mayoriacutea de las APIs disponibles en el mundo de la Websemaacutentica como JENA o SESAME y por los motores de almacenamiento de datos semaacutenticoo tripleStores maacutes conocidos como Virtuoso o Fuseki
Mediante estas soluciones se pueden construir puntos de acceso SPARQL que permitenconsultar datos mediante APIs protocolos web HTTP o interfaces graacuteficas de usuario
Alternativamente a los puntos de acceso disponibles mediante una interfaz de usuario comolos citados en los ejemplos anteriores es posible invocar peticiones de datos desde unnavegador incluyendo los detalles de la consulta en la URL de llamada aunque este meacutetodotiene algunas limitaciones A continuacioacuten se describe su utilizacioacuten
Ejemplos de puntos de acceso SPARQL implementados a partir de la tripleStore Virtuoso en diferentes portales de Datos usando interfaces de usuario
httpsdatosgobesessparqlhttpswwweuropeandataportaleusparql-managereshttpsdataeuropaeueuodpenlinked-datahttpdbpediaorgsparql
42
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Una forma de hacer este tipo de llamadas y obtener los resultados tal como los devolveriacuteaun navegador usando la barra de direcciones es utilizar el comando curl que permite latransferencia de archivos de datos usando diferentes protocolos entre ellos HTTP Estecomando se puede utilizar para invocar una peticioacuten a cualquier API REST
En el comando curl es posible incluir cualquier tipo de consulta SPARQL entrecomillada acontinuacioacuten de la clausula query= El paraacutemetro --data-urlencode se encarga de codificarla
Con el paraacutemetro -o se indica el nombre del archivo devuelto por el comando curl Esposible indicar el tipo de formato devuelto usando el paraacutemetro -header
Por ejemplo
--header Accept textcsv devuelve un archivo en formato CSV
--header Accept applicationsparql-results+json devuelve un archivo en formato JSON
Por ejemplo el siguiente comando puede ser ejecutado desde una ventana de terminal o decomandos y devuelve el listado de todas las URIs de todos los datasets contenidos en elcataacutelogo datosgobes en un archivo CSV
curl -k -o datasetscsv -G httpsdatosgobesvirtuososparql --header Accepttextcsv --data-urlencode query=select distinct dataset where dataset althttpwwww3orgnsdcatDatasetgtldquo
La salida del comando anterior contenida en el archivo datasetscsv es
datasethttpdatosgobescatalogoa02002834-relacion-de-codigos-de-municipios-de-aragon1httpdatosgobescatalogol02000011-centros-culturaleshttpdatosgobescatalogol02000011-centros-sanitarioshttpdatosgobescatalogol02000011-municipios-de-cadizhttpdatosgobescatalogol02000011-padron-de-espanoles-residentes-en-el-extranjerohttpdatosgobescatalogol02000011-patrimonio-de-diputacion-de-cadizhttpdatosgobescatalogol02000011-retribuciones-personal-eventual-de-la-diputacion-de-cadizhttpdatosgobescatalogol02000011-vertederoshellip
05
43
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
El comendo curl no es la uacutenica forma de realizar una consulta como la indicada en elejemplo anterior Tambieacuten es posible realizar una peticioacuten SPARQL utilizando directamente elprotocolo HTTP sobre un navegador
Es conveniente sentildealar que los navegadores web utilizan lsquoURL encodingrsquo para convertir loscaracteres que componen una URL a un conjunto de caracteres ASCII vaacutelidos para sertransmitidos a traveacutes de la red El encoding de URLs reemplaza caracteres ASCII no validospor ejemplo espacios en blanco por cadenas que contienen un caracter ldquordquo seguido de dosdiacutegitos hexadecimales Aunque los navegadores realizan esta operacioacuten automaacuteticamenteexisten muacuteltiples herramientas para hacer esta conversioacuten
Por ejemplo la siguiente peticioacuten hace uso del punto SPARQL de la dbpedia para recuperarla relacioacuten de grupos musicales
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX+dbpedia-owl3A+3Chttp3A2F2Fdbpediaorg2Fontology2F3E0D0APREFIX+esdbpp3A+3Chttp3A2F2Fesdbpediaorg2Fproperty2F3E+0D0APREFIX+esdbpr3A+3Chttp3A2F2Fesdbpediaorg2Fresource2F3E+0D0ASELECT+3Fgrupo++WHERE7B0D0A++3Fgrupo++rdf3Atype+++++++++++++++++++++++++dbpedia-owl3AMusicalArtist+0D0A7Dampformat=text2Fhtmlamptimeout=0ampdebug=on
La salida de la sentencia anterior obtenida como paacutegina web de un navegador es
05
44
La URL anterior es equivalente a la siguiente sentencia en SPARQL
httpesdbpediaorgsparqldefault-graph-uri=ampquery=PREFIX dbpedia-owl lthttpdbpediaorgontologygtPREFIX esdbpp lthttpesdbpediaorgpropertygtPREFIX esdbpr lthttpesdbpediaorgresourcegtSELECT grupo WHEREgrupo rdftype dbpedia-owlMusicalArtist
ampformat=texthtmlamptimeout=0ampdebug=on
grupo
httpesdbpediaorgresourceTommy_Marth
httpesdbpediaorgresourceAlaine_Laughton
httpesdbpediaorgresourceManuel_Salvador_Daacutevila
httpesdbpediaorgresourceSunYe
httpesdbpediaorgresourceNash_(banda)
httpesdbpediaorgresourceBobbi_Kristina_Brown
hellip
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
06APIs para el acceso a Servicios Web GeograacuteficosLos estaacutendares promovidos de el Open Geospatial Consortium (OGC) permiten lainteroperabilidad entre sistemas de geoprocesamiento y el intercambio de la informacioacutengeograacutefica
Dichos estaacutendares dan soporte a servicios Web geograacuteficos que son invocados por lasInfraestructuras de Datos Espaciales o cataacutelogos de Datos Abiertos
Entre otros son servicios web geograacuteficos relevantes los siguientes
ndash Los cataacutelogos de de servicios para la Web (CSW) que implementan servicios decataacutelogo de datos y servicios geograacuteficos basados en metadatos Es la norma dereferencia para exponer cataacutelogos de registros de datos geoespaciales en XML
ndash Los servicios de fenoacutemenos geograacuteficos (WFS) implementan los servicios deacceso a datos vectoriales en bruto permitiendo acceder y consultar todos losatributos de un fenoacutemeno o feature geograacutefico
ndash Los servicios de acceso a cartografiacutea (WMS) definen operaciones para laobtencioacuten de mapas como imaacutegenes la obtencioacuten de capacidades del servicio yla obtencioacuten de informacioacuten sobre puntos del mapa
OCG estaacute desarrollando OGCAPI para facilitar que cualquier organizacioacuten puedaproporcionar datos geoespaciales a traveacutes de la web Esta nueva implementacioacuten se estaacuteconstruyendo en base a la especificacioacuten OpenAPI a partir de los estaacutendares de servicio webOGC mencionados
Ejemplo de invocacioacuten de un servicio web geograacuteficos
bull Cataacutelogo de servicios Web del Instituto Geograacutefico Nacionalhttpwwwigneswebignportalide-area-nodo-ide-ign
bull Mapa de cultivos y suelos naturales de Castilla y Leoacutenhttpsdatosabiertosjcyleswebjcylsetesmedio-rural-pescamapas-cultivos1284807624344
45
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Referencias
07
En esta seccioacuten se muestra una relacioacuten no exhaustiva de algunas especificacionesherramientas comunidades de praacutecticas y medios de divulgacioacuten relacionados directamente conla implementacioacuten de APIs Se trata de una relacioacuten orientativa de referencia en el momento dela redaccioacuten de esta guiacutea no obstante la disponibilidad de informacioacuten de caraacutecter teacutecnico ydivulgativo sobre APIs en la Web es muy abundante por lo que se recomienda al lector orientarlas buacutesquedas de documentacioacuten a temas especiacuteficos para ampliar el conocimiento sobre eldisentildeo e implementacioacuten de APIs
Especificaciones
OpenApis httpswwwopenapisorg GraphQL httpsgraphqlorg Odata httpswwwodataorg OGC httpswwwogcorg SPARQL httpswwww3orgTRsparql11-protocol DCAT 20 httpswwww3orgTRvocab-dcat-2
Herramientas implementar y generar documentacioacuten
Swagger httpsswaggerio API blueprint httpsapiblueprintorg RAML httpsramlorg APIDocs httpsapidocjscom io-docs httpsgithubcommasheryiodocs Apiary httpsapiaryio
46
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47
Referencias
07
Herramientas para testar APIs
SoapUI httpswwwsoapuiorg Mockable httpswwwmockableio Runscope httpswwwrunscopecom Postman httpswwwpostmancom RESTClient httprestclientnet
Divulgacioacuten sobre APIs
ProgrammableWeb httpswwwprogrammablewebcom Moesif httpswwwmoesifcom APIEvangelist httpapievangelistcom APIScene httpswwwapisceneio
Comunidades de praacutecticas sobre APIs en Gobiernos digitales
USA httpsdigitalgovcommunitiesapis Australia httpscommunitydigitalgovau UK httpstechnologybloggovuktagapi-design
47