47
Guía práctica para la publicación de Datos Abiertos usando APIs

Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 2: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 3: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 4: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 5: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 6: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 7: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 8: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 9: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 10: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 11: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 12: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 13: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 14: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 15: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 16: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 17: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 18: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 19: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 20: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 21: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 22: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 23: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 24: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 25: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 26: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 27: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 28: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 29: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 30: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 31: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 32: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 33: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 34: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 35: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 36: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 37: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 38: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 39: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 40: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 41: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 42: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 43: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 44: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 45: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 46: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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

Page 47: Guía práctica para la publicación de Datos Abiertos …...Complementan la disponibilidad de datos en ficheros descargables y aportan una serie de ventajas que hacen que sea un medio

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