For RBdigital audiobooks we generate manifests that include links to URLs that look like this:

https://api.rbdigital.com/v1/media/978ISBN/parts/1111/download-url?s3=2222&f=3333_01

Unfortunately, these links don't actually go to MP3 files. They go to application/json documents that look like this:

The CloudFront URLs expire after an unknown period of time (I left one over the weekend and it didn't work when I came back.)

The simplest solution on the server side is to make up a media type for these application/json documents, like "vnd.librarysimplified/rbdigital-audiobook-part+json", and serve the api.rbdigital.com links as that media type. The clients will need to be modified to recognize that media type, parse it, and make the secondary request.

There's also a solution that doesn't require changing the client. The circulation manager can serve audio/mpeg links that look like this:

http://

/{library}/works/{work-id}/fulfill/{format}/{part}

(The {part} bit is new.)

When the client requests such a link, the circulation manager retrieves the audiobook manifest from RBdigital, makes the intermediate request to the application/json document, and sends the mobile client a redirect to a fresh Cloudfront URL.

The first solution performs a lot better because we don't have to route 50+ chapter requests through the circ manager. The second solution doesn't require knowledge of an additional media type.

It would be best if we could send both links in a single manifest, as alternate representations of a given spine item, but that doesn't seem possible within the manifest format.