# API Backend: Versión 0.1 y 0.2
## Tecnologías usadas

* Google Cloud Storage (GCS)
** Utilizado para el almacenamiento de los ficheros.
* Google Datastore (GDS)
** Utilizado para almacenamiento de metadatos de los ficheros.
* Google App Engine (GAE)
** Plataforma en la que se despliega el Backend

## Dirección actual del backend

La API para hacer peticiones al backend de mokap está en la siguiente dirección:
api.mokap.es
El servlet que se encarga de procesar las peticiones se denomina backend. De esta manera, la url completa para hacer peticiones es http://api.mokap.es/backend

## Tipos de peticiones

Actualmente soporta dos tipos de peticiones http:
* GET: Para recuperar resultados de búsqueda. Devuelve descriptores de los recursos que hay en el repositorio que incluyen un determinado texto de búsqueda.
* POST: Para subir nuevo contenido.

### Gestión de API Keys

Las peticiones tanto GET como POST están protegidas por un sistema de API Keys. De esta manera, el servidor únicamente atiende peticiones que incluyen un determinado API Key de 30 caracteres proporcionado por parámetro. Esto permite, por un lado, proteger el servicio de almacenamiento, y por otro lado, ahorrar recursos de Cloud en caso de que alguna entidad externa al proyecto intentara utilizar el servicio.
El sistema de autorización por API keys está pensado únicamente para su uso entre backends.
En el caso de que el servidor no reciba un api key, o este no sea válido, devolverá siempre como respuesta un código de error 403 (Unauthorized).
El api key se proporciona como parámetro dentro de la petición HTTP, ya sea GET o POST, de la siguiente manera:
url?k=API_KEY
De este modo, cualquier petición GET o POST desde la comunidad de Mokap debería empezar por:
http://api.mokap.es/backend?k=API_KEY

### Peticiones GET (v0.1)

Las peticiones get pueden recibir además dos parámetros adicionales de entrada:
* q: Texto a buscar
* c: cursor que devuelve app engine para búsquedas paginadas. En caso de que haya más resultados de los que pueden proporcionarse como resultado de un único request, AppEngine devuelve este valor cursor para que en una petición posterior puedan recuperarse la siguiente página de elementos. Lo único que hay que hacer es, en el caso de que el servidor devuelva que hay más elementos totales que los que contiene la respuesta, guardar el valor searchCursor y pasarlo como argumento en el siguiente request, y así sucesivamente hasta haber procesado todos los resultados.
Las peticiones devuelven como resultado un objeto JSON con los siguientes campos:
* total: Número total de resultados que contienen el parámetro de búsqueda proporcionado
* results: Una lista con los descriptores de cada uno de los elementos incluidos en la respuesta. La estructura de cada descriptor viene especificada por la clase RepoElement: https://github.com/e-ucm/ead/blob/master/build-tools/generators/src/main/resources/schema/editor/components/repo/repoelement.json
* No obstante, los campos más importantes son:
** contentsUrl: enlace para generar otra petición GET que recupera un zip con los contenidos del elemento (imágenes, código json para que funcione en mokap, etc)
** thumbnailUrlList: lista con thumbnails disponibles
* count: Un entero indicando cuantos elementos de entre los totales se incluyen en la respuesta. Debe ser siempre menor o igual a total. Equivale a results.length.
* searchCursor: puntero proporcionado por AppEngine para búsquedas paginadas. Se proporciona únicamente cuando count<total.
Ejemplo de petición get donde se busca por la cadena tree (q=tree):
http://api.mokap.es/backend?k=API_KEY&q=tree
Esto devuelve un resultado parecido al siguiente (v0.1):

### Peticiones POST

Para realizar una petición post hay que incluir el fichero a subir (siempre en formato ZIP) en el stream de la conexión. Este zip debe contener tres cosas:
* Una carpeta thumbnails con el thumbnail del elemento en distintas resoluciones. Los thumbnails deben ser siempre pngs no entrelazados, con transparencia, codificación de colores RGBA no indexada. La resolución de cada thumbnail se especifica en el nombre del fichero de la siguiente manera: anchoxalto.png
* Un fichero contents.zip con el elemento en sí (debe ser autocontenido).
* Un fichero descriptor.json con el RepoElement que describe el elemento en el catálogo del repositorio.
Así pues, el fichero a subir debe tener la siguiente estructura (asumiendo que el fichero se llama id_elemento.zip):
id_elemento.zip/

### Cambios de la v0.2:

Hemos decidido que no tiene sentido recibir una lista de thumbnails en cada petición y para cada elemento por lo que hemos refactorizado la gestión de thumbnails de la siguiente manera:

### Peticiones GET (v0.2)

Se han añadido los siguientes parámetros de entrada:
* w: Opcional, Integer, indica al servidor qué anchura te thumbnail esperas que tengan los elementos en la respuesta. Este tamaño es una mera indicación que servirá para que el servidor escoja el thumbnail con la anchura más apropiada según lo que se le ha indicado en este campo para cada elemento.
* h: Opcional, Integer, en este caso le indica al servidor la altura del thumbnail esperado en cada elemento.
Ojo pues si el servidor no encuentra un thumbnail con exactamente el tamaño buscado devolverá el que más se acerque, así que no hay que tratar estos parámetros como garantía de que los thumbnails tendrán el tamaño indicado.
Nótese cómo los elementos del repositorio (RepoElement) ahora disponen de un campo adicional thumbnailUrl. Este será el campo de la respuesta que contendrá la dirección del thumbnail elegido por el servidor en función de los campos w y h proporcionados en la petición.
Por ejemplo, un elemento de la petición anterior adaptada a la v0.2 sería:
http://api.mokap.es/backend?k=API_KEY&q=tree&w=500&h=500
Donde obtendremos como respuesta :