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.
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. The maximum allowed age a of both parameters is currently 180 days but might change in the future. If a customer needs to fetch older information than this, please contact Bokbasen on a case by case basis.
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.
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.)
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.
The "Next" response header is always present. When the current response does not contain any records the Next response header is unchanged.
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.
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.
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 formated reports the response will be in plain text instead of xml.
|Default (and max) pagesize for ONIX||1000|
|Default (and max) pagesize for Object Report||5000|
|Maximum age of after and next parameters||180 days|
|Maximum age of Object reference link||24 hours|
|Allowed time skew between server and Date in request header||15 minutes|
Pagination and Pagesize sample
Request with after and thereafter a request using the returned Link header.
Request with valid Authorization token and Date. But is missing mandatory parameter subscription.
Request with valid Authorization token and Date. But is missing next or after parameter.
Request missing required headers.
Request with valid Authorization token, and a Date of invalid format.
Request with valid Authorization token, and a Date that is of valid format but is not within the boundary of 15 minutes skew.
Request with expired Authorization token and valid Date.
Request with valid Authorization prefix but invalid token and valid Date.
Request with invalid Authorization prefix and valid Date.
When the request is fine, but an unexpected error occurs at the server side, the client will receive the following response.