disunity-hq / disunity

A fullstack toolchain for modding Unity games
MIT License
20 stars 4 forks source link

V1 API Spec #30

Open dustinlacewell opened 5 years ago

dustinlacewell commented 5 years ago

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.

scottbot95 commented 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. 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.