V1 API Spec

[dustinlacewell]

Let's get together and enumerate the possible routes that should be part of V1. This will greatly help doing #25 . We can also try to think about what API support will be needed by the exporter and managers.

[scottbot95]

As far as the manager goes, I don't think it really needs much. It's going to need at least:

1. A listing of all mods
   • Should include basic information like name and owner, download count probably
2. A listing of all versions for each mod
   • Should contain detailed information like dependencies, disunity compatibility and so on
3. A listing of all targets
   • Probably just needs to be the name of targets and maybe some version information?
4. A way to determine the target given a hash

1 and 2 can most likely be combined without too much trouble; likewise for 3 and 4.

With that in mind I propose the following api scheme:

Route	Description
/mods	Returns a JSON array with details of all mods and their versions. Should most likely have pagination and some level of filtering (namely by target compatibility) via the query string.
/targets	Returns a JSON array of all the targets with their versions and disunity compatibilities. Optionally accepts pagination and filtering via the query string`
/targets/find?hash=	Looks up a target by it's hash and returns either 404 or a JSON object with all the same info provided by the /targets route. With that in mind this route might be superfluous

We can have individualized routes like /mods/{modId} but I feel like they won't be particularly useful as the only time you'll be able to use them is if you already know the ID is by looking them up with the view all route.