...
This service provides access to each Bokskya's end user's bookshelf.
All text marked in RED is functionality not yet ready for testing, this is only functionality required for caching of OPDS feed, please come back to this page to see when this is released as soon as it is ready in august 2015.
Get OPDS
Get personal bookshelf for DDS user in OPDS XML format.
...
URL | https://api.dds.boknett.no/catalog/personal/{ddsId}
| ||
Method | GET | ||
Request headers | Authorization | Required | The token acquired from the Authentication Service. Formated "Boknett TGT-...." |
Date | Required | The timestamp the request was made. Must comply with RFC 1123 date formats. Example: Tue, 10 Jun 2014 16:23:42 GMT | |
If-Modified-Since | Optional | Used for client caching of feed. See chapter on performance considerations below. See RFC for details. | |
Response body on success | XML OPDS feed (See below) or empty body if using "If-Modified-Since" and response is 304. | ||
Response headers | Last-Modified | Date header showing last time this user's OPDS feed was updated (see RFC for details). Use this date in "If-Modified-Since" when doing your subsequent request. | |
Returns | 200 | OK | |
304 | Not modified | ||
40x | On error |
...
Performance considerations
From a computation perspective this is the heaviest API endpoint in DDS and that combined with that the data in each users bookshelf have a low update frequency, this is a strong candidate for client caching. The API provides specific functionality for this, and we highly recommend you to implement caching of the feeds on the client side to improve consumers user experience.
To support client caching in a efficient way the end point support the "If-Modified-Since" HTTP header, allowing for a quick way of checking if there has been any changes from last time the feed was loaded. When doing a request with this header, you will either receive a 200 OK with a body (meaning there was a changes since last time) or a 304 Not Modified with an empty body (meaning there was not change, so you should go ahead and used you cached version).
Technical details can be found here:
- Last-Modified response header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29
- If-Modified-Since header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25
Note: When using the If-Modified-Since header it is recommended that you use a date retrieved from the Last-Modified header of a previous request to the same service. The reason for this is that the service expects that the parsed date retrieved from the If-Modified-Since-header is an exact match (with millisecond precision) to the date used in the Last-Modified header. The service still respect and parses all the date-formats mentioned in http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1.
NOTE ON TESTING THIS: In the current version of DDS in the test environment this is not fully implemented, it will be released in the next version. This will still work, but the 304 response is currently not more performant than a normal request. This will change significantly in the next release, so implementing support for caching and 304 is highly recommended.