Instructions
After registering an API user, you need to authenticate and obtain a bearer token from the webservice. This is done by sending a POST request to
https://aemp.trusted.dk:443/Token
with the following header included
Content-Type: application/x-www-form-urlencoded
The request body must contain the following:
grant_type=password&username=[username]&password=[password]
Assuming that the request succeeds, the response body will look similar to this
{
"access_token":"boQtj0SCGz2GFGz[...]",
"token_type":"bearer",
"expires_in":1209599,
"userName":"[username]",
".issued":"Mon, 14 Oct 2020 06:53:32 GMT",
".expires":"Mon, 28 Oct 2020 06:53:32 GMT"
}
(For readability, the access token has been truncated and indentation added.)
The token is only valid until it's expiration time. After expiration, or any time before, you can obtain a new token.
In order to send an authorized request to the web API, insert the obtained token in the request header like this:
Authorization: Bearer boQtj0SCGz2GFGz[...]
As is allowed in ISO/TS 15143-3 standard, the server will cache any response for 15 minutes and will serve a cached response if requested again in that timeframe.
Technically this means that a response will have a Cache-Control: max-age=900 header as well as a Date header.
This caching is enforced by the server on a pr request basis.
Clients cannot bypass the serverside caching, but can optionally implement standard cache validation, if there is a need to ensure that no stale data is served:
In addition to MaxAge, we will issue an ETag header. You can use the Etag value to make a followup request with a If-None-Match header of that Etag value .
This will force a re-evaluation of the resource on the server. If the resource is still valid, server will then respond with a 304 status code.
Otherwise it will respond with the updated resource (and a new Etag)
For example:
GET /api/v2/Fleet/2
Accept: application/xml
Authorization: Bearer boQtj0SCGz2GFGz[...]
Status Code: 200
Cache-Control: max-age=900
Content-Length: 24
Content-Type: application/xml; charset=utf-8
Date: Fri, 27 20202 12:00:00 GMT
ETag: "5c479911-97b9-4b78-ae3e-d09db420d5ba"
Server: Microsoft-IIS/10.0
On the next request:
GET /api/v2/Fleet/2
Accept: application/xml
Authorization: Bearer boQtj0SCGz2GFGz[...]
If-None-Match: "5c479911-97b9-4b78-ae3e-d09db420d5ba"
Status Code: 304
Cache-Control: max-age=900
Content-Length: 0
Date: Fri, 25 Jan 2020 12:05:00 GMT
Server: Microsoft-IIS/10.0
Following the ISO/TS 15143-3 standard, the default response format will be application/xml. This will be assumed if no AcceptHeader is set or it is set to */*
Each version of the ISO/TS 15143-3 standard describes a model and custom mediatype header, this can be used to request a dataset in a specific format
If not using one of the versioned MediaTypes in the request, Version 1 (20161201) will be used
The supported MediaTypes in AcceptHeader are: