fairingrey / rustpixiv Goto Github PK

Thinking about how authentication should act in hindsight, it might be better to let the user handle a Result type in the case they're trying a multitude of valid/invalid logins, or their refresh token has expired from pixiv and they should try using the password grant type.

Lines of interest:

https://github.com/fairingrey/rustpixiv/blob/master/src/lib.rs#L304
https://github.com/fairingrey/rustpixiv/blob/master/src/lib.rs#L340

Reference:

• https://github.com/upbit/pixivpy/wiki/Sniffer-for-6.x-API-v2-endpoints
• https://github.com/upbit/pixivpy/blob/master/pixivpy3/aapi.py

There are 5 new endpoints that I'm aware of:

• https://app-api.pixiv.net/v2/illust/follow -- GET
• https://app-api.pixiv.net/v2/illust/related -- GET
• https://app-api.pixiv.net/v2/illust/bookmark/detail -- GET
• https://app-api.pixiv.net/v2/illust/bookmark/add -- POST
• https://app-api.pixiv.net/v2/user/list -- POST

Will cross-reference other libraries when I need to.

Note that AppAPI is broken on pixivpy (no-auth requests no longer work, even with auth it doesn't work), which is why I didn't implement it yet. Wanted to get something rudimentary published first (as of opening this issue I'm still leaving the version at 0.1 until I'm more confident).

Do more testing/experimentation with it, see if it's usable.

Depending on how testing it goes, may override some v1 methods? Could be another big breaking change (v1 support will probably go into its own separate module if so)

• v2 API likely still doesn't care about the User-Agent header and all that other junk, but if it does, take note.

Currently, API is tied to reqwest as HTTP client so anyone who would want to use own HTTP Client would be unable to do it as Pixiv and PixivRequestBuilder are tied to it.

So what would be better if we could use
PixivRequestBuilder to create PixivRequest

And then user would need to pass PixivRequest to Pixiv for execution.

Pixiv itself would be in a separate module and optional, only if user would not disable default feature that enables reqwest

Most likely it would require to rename it.

Most likely ready to be send PixivRequest would its field to be public so that user could create request from it.
As most existing HTTP clients use http crate for basic primitives it should be easy to use it with any other clients

P.s. Well I'd like to have this separation because I prefer my own HTTP client to reqwest

Just notes to myself, but...

#1 has introduced a few potential breaking changes

• Pixiv::new now clones a given reqwest client.
• PixivRequestBuilder now borrows a Pixiv instead of a Client

And also a lot of QOL things. Some errors on authorization now panic instead of trying to use an unexpected result (which is good), and certain function signatures have changed to accept more generic arguments using traits (namely favorite_works_remove and others like it).

I'll be updating this as I go since I haven't looked at absolutely everything, but I should test/review it all and push a new version soon.

This probably should be removed or hidden behind some kind of debug gating (although I don't know what the standard way to do this is).

Thank you for the crate btw.