APIv2: `/item` at root level, will muddy up versioning with `/api/v#`

[ghukill]

Might need to change links to /api/item globally. This would include DPLA metadata...

OR, we have a dedicated Flask route to redirect, or apache redirect for /item --> /api/item

[ghukill]

A few routes in APIv1 have apache reverse-proxies at the root level:

• /item
• /iiif_manifest

Maybe (probably others). If we version the APIs, multiple APIs cannot have routes at /item, for example.

One approach might be to create a redirect at the root level, /item that points to /api/item, which will effectively hit the most recent api version.

Or, we look into removing routes at the root level. This would require some metadata changes, e.g. DPLA mentioned above, but would be easier to maintain.

[ghukill]

Actually, we could change the apache reverse-proxies to just add /api/[whatever].

So, in Apache, /item would reverse-proxy to /api/item, and we'll just have to make sure that upgrades to API versions don't break those few things that have root level redirects like that.

[ghukill]

Conferred with @colehudson on 12/8 about routes for things like /item. Updates that close this issue:

Our approach will be to think of the front-end as a wrapper around the API in many ways. The API will certainly respond on its own at /api/ROUTE, but will also receive requests from the front-end under various "catch-alls". These catch-alls will fire when the front-end does not have a more specific route. Example:

• /item/<pid>/ will return HTML page
• /item/<pid>/metadata might return interesting metadata, still HTML though
• /item/<pid>/file/MODS will directly pipe a response from /api/item/<pid>/MODS
• similarly, /item/<pid>/goober/tronic/foo/bar would also do the same (though this route likely doesn't exist on the API

In this way, we maintain a very close relationship between the front-end and the API, but both exist on their own terms as well.

Interestingly, similar routes will be shared by both, such as /item/<pid>. The front-end returns HTML, the API returns JSON from /api/item/<pid>. If we ever wanted to introduce content-negotiation, the front-end would handle this, essentially just appending /api to responses where API content is requested.