Implement APIs for fetching VitalSource book and chapter metadata

[robertknight]

Implement backend API views that can be used by the frontend to fetch metadata (title, cover image) for a VitalSource book and retrieve the list chapters in a book. See the video in https://github.com/hypothesis/lms/pull/2953 for context.

VitalSource has APIs that can be used to retrieve metadata for a book (called a "product" in their API docs) and the list of chapters (aka table of contents or "toc" in their API docs). See these notes for details.

The frontend needs the following APIs:

1. Book metadata API

The user will paste a link to a VitalSource book into the UI, from which the frontend will extract a book ID (aka "VBID"). It will then make an API call to the backend, passing the book ID, to fetch details about the book. The backend should query the VitalSource product information APIs. If the book exists then a subset of the metadata should be returned to the frontend:

• Book ID
• Book title
• Cover image URL

If the book does not exist, a 404 response should be returned.

2. Chapter list API

Once the user has entered a book link and it has been validated, the frontend will fetch the list of chapters in the book by making an API call to the backend. The backend needs to provide an API that accepts a book ID and returns a list of chapters. For each chapter, the frontend needs the following fields:

• Title
• Page number
• CFI (this is an XPath-like expression that indicates the location of the chapter within the book. This is used to launch the VitalSource book viewer at the correct location for the chapter)

VitalSource API details

Details of the APIs can be found at https://developer.vitalsource.com/hc/en-us/articles/360010967153-GET-v4-products-vbid-Title-TOC-Metadata.

• Book metadata can be fetched via https://api/vitalsource.com/v4/products/{BOOK_ID}
• The chapter list can be fetched via https://api/vitalsource.com/v4/products/{BOOK_ID}/toc

Authentication requires an API key, which only depends on the calling application (ie. the LMS app) and does not need to depend on who the LMS user is. We have an API key which we can expose to the LMS app as an environment variable. I do not know if the API has a rate limit, but since we only need to use the APIs when creating an assignment, our usage of them is likely to be quite low (in terms of requests/minute).

In the absence of these APIs, the frontend views currently use hard-coded data which has been previously extracted from the VitalSource APIs. This data gives an example of the format that the frontend currently expects to work with.

Part of https://github.com/hypothesis/lms/issues/2861.

[robertknight]

I drafted a PR to implement stub API views at https://github.com/hypothesis/lms/pull/2831. This doesn't actually call the VitalSource APIs, it just exposes the dummy data that currently lives in the frontend via a backend API instead.

Please feel free to use as much or as little of this as you want.

[seanh]

Note that there's already a VitalSourceService in the code. VitalSourceService doesn't currently send API requests to the VitalSource API. But if a service is needed for these API requests (if they aren't simple enough just to put directly in the views) then we should probably keep it in the same place as the existing VitalSource-related service code.

Also, HTTPService should be used for sending HTTP requests

[robertknight]

https://github.com/hypothesis/lms/pull/2831 has been revised and merged, so there are now stub API views in lms.views.api.vitalsource which need to be filled out with implementations that actually call the VitalSource APIs.

[robertknight]

Related PR: https://github.com/hypothesis/lms/pull/3009. @marcospri I think this is done now?