API design

[Marlamin]

Required endpoints, etc. Read-only stuff first, please.

https://petstore.swagger.io/#/ seems like a good base.

[Marlamin]

https://api.wow.tools/swagger/index.html

Current idea is up at the above URL. Only the /tactkeys endpoint is implemented right now.

Feedback on which endpoints there are/what data is exposed is welcome, some parameters are in the midst of being changed around so don't mind those.

[Meorawr]

In terms of LibRPMedia our data exporter uses the following currently:

• Database exports (via /api/export/?name=<name>&build=<build>).
• Filelist dumps (via /casc/listfile/download/csv/build?buildConfig=<build>).
• Additionally I've got a branch which is using the current /api/data/tactkeylookup and /api/data/tactkey endpoints.

The proposed API looks mostly good enough to cover my use cases there, with a few notes:

/files
There doesn't seem to be an endpoint for getting a full listfile for a specific build (mirroring the endpoint I'm using above) unless that's the intended functionality of /builds/{buildConfig}/files? Currently it looks like I'd have to get the full list via /files and then issue a request to /files/{fileDataID}/versions for each one to figure out whether or not a specific file is present in a build.

Additionally as JSON is supported as an export format for databases, would it make sense to also extend this to the listfile?

/tactkeys
The TACTKeys endpoints looks great. Would it be possible to additionally have a reverse lookup to get the list of TACTKeys used by a single file (identified by its file ID, or content hash if applicable) - such as /files/{fileDataID}/tactkeys? I'd have a potential (and very minor) use case for it, but if it isn't trivially possible then I can just make the reverse mapping myself via what's already proposed.

[Marlamin]

You're right, listfiles likely have a place here as well and I don't see why they shouldn't be a part of it. Will keep that in mind next time I work on it. JSON listfiles are probably doable as well though that ends up being some pretty hefty JSON to read.

As for what tactkey a file is encrypted with, that's definitely doable. Might just include that in the /files/{fileDataID} endpoint instead of making a separate one for it.

Thanks for the feedback!