search

lazeroffmichael / ticktick-py

Unofficial TickTick API
https://lazeroffmichael.github.io/ticktick-py/
MIT License
212 stars 29 forks source link

Using the OpenAPI vs. Reverse Engineering the internal API #38

Open btw04 opened 1 year ago

btw04 commented 1 year ago

TickTick's official API in its current form only allows very limited access to a small selection of features, anything besides working with tasks is impossible.

There are some other features that some might want to interact with via an API. I wanted to start this discussion to talk about the desired goal of this repository as I myself have started to become involved in developing some of its new features. The only way to add said features is using the internal API HTTPS Endpoints which can be reverse engineered with a simple analysis of the website and can be used to implement almost all interactions with the TickTick platform. But, there is a big caviat. This might be against the ToS (https://ticktick.com/about/tos).

I argue that implementing features using the internal API is still fine, as long as there is no offical way to achieve the same things. Adding well researched, tested and safe components to this repository is the only possibility for a small group of people that want to automatically interact with the TickTick platform, and there is no alternative to using the internal API.

However, I understand if @lazeroffmichael does not want this repository to go into this direction. We all hope that TickTick will someday provide an official API that would resolve all of these issues, but until then this is the decision that has to be made.

lazeroffmichael commented 1 year ago

Thank you for opening this discussion up! It would be ideal if we could migrate everything over to using officially supported endpoints, but sadly until that day comes we will have to make do with the current options.

C0rn3j commented 1 year ago

I think it would make sense to have a configurable option in the library with 3 states.

  1. OpenAPI only, the default state
  2. OpenAPI + internal API for unavailable functions
  3. Internal API only

I do not use this library at the moment, I have been writing my own small project that interacts with OpenAPI but was disgruntled when I found out I can't even get a list of all tasks without making requests to every single "Project" included, or can I access my filters with it.

Number 3. makes sense to me as TickTick could drop OpenAPI support at a future point, at which point this library would have to change course, and planning for support for it ahead may be a good idea.