Open dustinlacewell opened 5 years ago
As far as the manager goes, I don't think it really needs much. It's going to need at least:
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.
Let's get together and enumerate the possible routes that should be part of V1. This will greatly help doing disunity-hq/disunity#25 . We can also try to think about what API support will be needed by the exporter and managers.