Initial API design

[43081j]

We need to decide what the initial API MVP is, the basic shape.

Path	Methods	Purpose
/{packageId}	GET	Retrieve a single package, with all versions
/{packageId}/{version}	GET	Retrieve a single package at a specific version

More to be added soon, and these may not be right yet. @ghostdevv will need your help filling this table in

[ghostdevv]

some quick thoughts:

1. I think we should prefix the routes with a version, e.g. /v0
2. Should we do pagination on endpoints that return potentially large arrays like all the versions?
3. Do we allow people to provide a version range, or do we always require an exact version and provide a seperate endpoint for resolving a version (if they don't want to do it themselves with the data we provide or otherwise).
4. Should we do /{packageId}/{version} or /{packageId}@{version}?

[ghostdevv]

3. Do we allow people to provide a version range, or do we always require an exact version and provide a seperate endpoint for resolving a version (if they don't want to do it themselves with the data we provide or otherwise).
4. Should we do /{packageId}/{version} or /{packageId}@{version}?

Interestingly jsdelivr's data api requires an exact version and has an endpoint to resolve a version, but also does package@version 🤔

[43081j]

1. yes definitely
2. yes. npm doesn't do this but we should (for {package}/ especially)
3. i think i'd require a version but maybe we could have a query endpoint in future that has a version filter, so its more like a search than a get
4. i think {id}/{version} will be easier to maintain and means the backend doesn't need to "parse" it (whatever we use for the API will presumably already have a concept of path parts)