There are 3 patterns to publish data through Meteogate with more details found in the documentation
Instructions in this repository concentrate on publishing Pattern 2: Managed and Proxied Access Through MeteoGate API Gateway.
- Observations (E-SOH)
- Radar (ORD)
- Climate
- Warnings (MeteoAlarm)
The Data Supply component is registered with an appropriate MeteoGate API Gateway. Currently, these are deployed on the EWC, in ECMWF and EUMETSAT runtime environments. EUMETNET Members will connect their data services via EWC irrespective of the location of their data (e.g., EWC, public cloud, on-premises). In the future, if requirements change, MeteoGate API Gateway can be implemented also on public clouds.
The data is requested from and goes through the MeteoGate API Gateway allowing:
- Managed data requests and data flow e.g., authorization, access control, and rate limiting
- Collection of insights on data requests and access.
This pattern is appropriate for the following situations:
- There is no suitable HVD service (Pattern 1) for the type of data to be shared.
- Data is hosted on EWC, or data access APIs will be hosted on EWC.
- Prefer minimal IT investment while ensuring the data is discoverable, accessible, and compliant with MeteoGate requirements.
- Want to benefit from improved security, efficiency, manageability, and cost-effectiveness, as MeteoGate handles security, rate limiting, and monitoring.
Read more about the MeteoGate API Gateway features on MeteoGate Architecture.
- Use your own API / file hostings and adverise direct links to data
- Add discovery metadata to WIS 2
- Add notifications to WIS 2 (that point directly to your service)
The following sections contain the requirements for your API and detailed steps on publishing your data using Pattern 2.
- What kind of ratelimiting do you want to enforce for users accessing your API through Meteogate?
- Do you want the API to be publicly accessible or only to users registered to Meteogate?
- Does your API require authentication to access?
- For best user experience, ensure your API is capable of handling and providing dynamic URLs
- i.e. if your API returns any URLs back to the API published they should not be hardcoded and instead use the origin URL
- Make sure you've gone through the considerations and requirements
- Copy one of the example configurations in the examples folder in this repository which best suits your needs
- Fill in your API details to the configuration file
- Any API is ok (WMS, EDR, openapi)
- For
idandroute.idfollow the naming convention<country code>-<organization>-<API type/name>-<additional information>where additional information is optional and all other mandatory- e.g.
fi-fmi-edr,fi-fmi-timeseries,eu-eumetnet-surface-observations,fi-fmi-wms-forecast - The
idwill be the route postfix used to access through MeteoGate e.g.https://api.meteogate.eu/eu-eumetnet-surface-observations
- Choose rate limits to users (optional)
- For unregistered users we enforce default ratelimits
- Choose to allow anonymous and / or only registered users access
- By default anonymous access is allowed with the default ratelimits
- Set upstream API authentication (between MeteoGate API GW and your API) if needed
- Provide the correct
headerwithheaderParamused for authentication with your API - e.g.
Authorization,X-API-Key
- Provide the correct
- set CORS header
- Save the config file
- Contact Meteogate service desk through contact form
- In the message provide the
configurationas a code snippet which is accessible by pressing the+in the description field - If your API requires upstream API authentication provide the
API-KEYin the message as a separate code snippet - If accessing your API requires whitelisting of ip block please state that in the message
- In the message provide the
- Wait for somebody from the MeteoGate team to contact you
- When the onboarding process is complete
- Test your api through MeteoGate API gateway at
https://api.meteogate.eu/<route_id> - Test registered access by registering your own apikey at https://devportal.meteogate.eu/
- Test your api with apikey at
https://api.meteogate.eu/<route_id>?apikey=yourapikey(or put apikey in the header of the request)
- Test your api through MeteoGate API gateway at
id: fi-fmi-edr <- Follow the naming convention
version: 1.0.0
platforms:
- EUMETSAT
- ECMWF
routes:
- route:
id: fi-fmi-edr <- Follow the naming convention
endpoint: https://opendata.fmi.fi/edr
ratelimitAnon:
requestRate:
rate: 10 <- Anonymous users are restricted to 10RPS by default
burst: 20
quota:
count: 50 <- Anonymous users are restricted to 50RPH by default
time_window: 3600
cors: true
id: fi-fmi-edr
version: 1.0.0
platforms:
- EUMETSAT
- ECMWF
routes:
- route:
id: fi-fmi-edr
endpoint: https://opendata.fmi.fi/edr
ratelimitAnon:
requestRate:
rate: 10
burst: 20
quota:
count: 50
time_window: 3600
ratelimitAuth: <- Added limits for authenticated users
requestRate:
rate: 60 <- 60 RPS
burst: 100
quota:
count: 500 <- Define the amount
time_window: 3600 <- Define the time window in seconds
cors: true
id: fi-fmi-edr
version: 1.0.0
platforms:
- EUMETSAT
- ECMWF
routes:
- route:
id: fi-fmi-edr
endpoint: https://opendata.fmi.fi/edr
apikeyOnly: true <- Only users registered to MeteoGate have access
ratelimitAuth:
requestRate:
rate: 60
burst: 100
quota:
count: 500
time_window: 3600
cors: true
id: fi-fmi-edr
version: 1.0.0
platforms:
- EUMETSAT
- ECMWF
routes:
- route:
id: fi-fmi-edr
endpoint: https://opendata.fmi.fi/edr
ratelimitAnon:
requestRate:
rate: 10
burst: 20
quota:
count: 50
time_window: 3600
apikey:
headerParam: 'Authorization'
secretName: FI-FMI-EDR-KEY
cors: true
id: fi-fmi-edr
version: 1.0.0
platforms:
- EUMETSAT
- ECMWF
routes:
- route:
id: fi-fmi-edr
endpoint: https://opendata.fmi.fi/edr
ratelimitAnon:
requestRate:
rate: 10
burst: 20
quota:
count: 50
time_window: 3600
ratelimitAuth:
requestRate:
rate: 60
burst: 100
quota:
count: 500
time_window: 3600
apikey:
headerParam: 'Authorization'
secretName: FI-FMI-EDR-KEY
cors: true