Open micah686 opened 2 years ago
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
Expression<TReturnType>
to grab the fields requested and convert it to the fields
property in the request... Ew.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.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.
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),