Per tal de poder fer consums els clients s’han de subscriure a un o diferents plans de consum. Cada un d’aquests plans permet accedir a un conjunt de recursos d’un tipus determinat, i disposa d’una quota d’accés, és a dir, d’un número de peticions màximes d’aquest tipus que l’aplicació pot fer per període de temps. Així doncs, per exemple una aplicació d’un client podria estar subscrita a un pla de consum de dades de la XEMA i un altre diferent de dades de la XDDE.

Les quotes de cada pla són mensuals. Si durant aquest periode es supera el nombre de consultes permès, l’API retornarà un error del tipus 429 – Too Many Requests (podeu consultar la secció d’errors per a més informació). El nombre de consultes disponibles torna al seu valor original el primer dia de cada mes a les 00:00 (UTC).

A més a més, l’API té un límit de consultes per segon, per tal de no saturar el sistema i assegurar un correcte funcionament a tots els usuaris. Si es supera aquest límit, que actualment és de 1000 peticions per segon, l’API retorna un error del tipus 429 – Too Many Requests.

En tot moment un client pot consultar el seu consum actual mitjançant una consulta a l’API. Cal destacar però que hi ha un retard d’uns minuts entre la realització d’una consulta i que aquesta es vegi reflectida al còmput de consum actual.

Com s’han de fer els consums? Servidor i Caché

Els consums s’han de fer des de una aplicació de servidor, que idealment ha d’implementar un sistema de caché. Amb això obtenim dos beneficis immediats:

• l’API KEY no queda exposada als clients de l’aplicació, que la podrien utilitzar per fer els seus propis consums.
• Amb un sistema de caché, cada petició d’un client final de l’aplicació NO implica una petició a l’API REST de dades meteorològiques. Amb això s’estalvien consums innecessaris que poden fer que la quota del pla contractat s’exhaureixi ràpidament.