HTTPS Api

[micah686]

Yorhel has announced a new HTTPS based API (https://api.vndb.org/kana). This should be a better method of interacting with VNDB, since it works over HTTPS, which should reduce security issues (Like SecureString on non-Windows),

[Nikey646]

Sorry for the delayed response, was on holidays.

Due to the fact that the old API won't be going away for the foreseeable future,

This version of the API is intended to replace the old TCP-based API, although the old API will likely remain available for the forseeable future.

This would most likely be an addition on top of the existing infrastructure.

Running through implementation issues and just dumping initial thoughts

• The fields system is very... graphql-esq. Makes me wonder why this wasn't just a graphql API, despite not liking that system in general. It's just a more complex / annoying way to select data.
  • This is made worse by the fact that every field needs to be explicitly mentioned. To use the current flags system that we're used to would be very... non-extendable. Providing the user a way to select data on the method would likely require reading the AST from an Expression<TReturnType> to grab the fields requested and convert it to the fields property in the request... Ew.
• The new filter syntax is even more... annoying compared to the previous pure text syntax. The nested nature would make this hard to implement, and would most likely have an opt out for complex filters unlike the current system asking for the filter data... Just even thinking about how I would accept a nestable data structure like the example complex filter as an argument is giving me a headache.
  • This might be automatically resolved by porting the existing filter infrastructure to return String[] for a filter, and the And / Or filters returning (String, String[]). But I doubt that this would actually work out and honestly, not a fan of this approach because it would make the whole process of defining complex filters in code very complex.
• No authentication at all at this point in time.

The design of the API, in my opinion, shows a clear case of "Not invented here" and rather than modifying the back end to make an existing system work, has pushed the burden onto the end users. This is shown in the obtuse filter syntax that apparently has 3 data structures (A "compact" string, the json, and a third intermediatory form), the GraphQL style field selection without just rolling a GraphQL api which would probably allow the implementation of the filters without the complex data structures.

Honestly, after a quick glance and taking into consideration that I do not use this library anymore I doubt I will personally implement this unless I have another use for the VNDB api and the TCP one has been taken down. I'm happy to help direct integration of the HTTPS api into this library, or help discuss any issues with creating a new library focused on the HTTPS api.