The export service provides alternatives for retrieving metadata and objects from Bokbasen. This pages contains general information covering all export services, see individual sub pages for the different data and formats that can be retrieved.

Pagination

All reports will require one of two parameters; after or next. The usage of the two parameters differs slightly. The HTTP response will always contain a token that represents a specific "internal timestamp" and can be used as a "cursor". This token can be used in the next request to get all changes since the last request.

Parameters

Open

Initial with after then with next (persist next from each session)

Open

Recursive calls until next doesn’t change

 

Next

Using the next parameter is the recommended way to invoke the report service. It is also the only possible way to implement incremental updates. The HTTP response from all report services will include a header containing a token that represents a specific "internal timestamp" that can be used as a "cursor". This token shall be passed with the next parameter in the subsequent request in order to retrieve all updates since the last request. This requires the customer to save the obtained token from each response and use it in the following request. If the token is lost, a new token can easily be obtained by making a new request using an older next or the after parameter.

After

Using the after parameter will allow clients to request records updated since a specific time. The parameter has a human readable format yyyyMMddHHmmss. The only recommended usage of the after parameter is (1) when non incremental updates are requested (for example all records updated last 2 months) or (2) when the token is lost. A response to a request with an after parameter will include a new cursor in the header as long as the resulting report is not empty. Using the after parameter for incremental updates can result in duplicated updates or "missed" updates. (The cause for this is that the timestamp on which both next and after is based, can be set to a value that is before current time.)

Pagesize

All reports have a default pagesize which is also the maximum pagesize. The client is free to choose a suitable pagesize between 1 and this maximum. If pagesize is omitted, or the requested pagesize exceeds the maximum, the services will handle the request using the default pagesize. All clients requesting reports should use the pagination facility when fetching a large number of records.

Response headers

Next Response header

The Next response header is always present. When the current response does not contain any records the Next response header is unchanged.

Link Response header

The Link response header is only present as long as there are more pages to process. When the current response does not contain any records the Link response header is not present.

Best practice

Using the Link response header is the recommend method to implement pagination. The client should keep sending requests as long as the Link response header is present. After the initial request the Link response header should be used in every subsequent request. 
It is also possible to implement pagination using the Next response header. If so, the client should keep sending requests as long as the Next response header does change from the preceding request.

Error Handling

Feedback

In case the request fails due to validation of request headers or input parameters the client will receive a response consisting of an xml explaining the cause of failure. The elements of the error xml are listed below. For some errors there may be additional elements included for better explanation of the error cause. For non-xml formatted reports the response will be in plain text instead of xml.

Restrictions 

Pagination and Pagesize sample

Parameter Error

Missing Headers Error

Date Header Error

Authorization Header Error (Boknett) Legacy

Authorization Header Error (Bearer) Future

System Error

Referenced documents