REST API

[clemera]

Have you thought about providing a REST API returning feed data as JSON? This would help implementing other UI interfaces. I will probably experiment with that and if your are interested provide a PR.

[lemon24]

I did, but only barely, because it sounds like a lot of work :) If I actually had time to do it, I'd like to have GraphQL API, or a "proper" RESTful API (as described here) that's also OpenAPI-compatible.

For the web app I was a bit more pragmatic and I made a very limited JSON API, but I am reluctant to expose it both because it's very limited, and because I have some "special" requirements (I need it to work both with JSON and with old-style HTML forms).

I am interested, but I currently don't have enough bandwidth to maintain it. If you are willing to do it, we can include it in reader as an extra, or it can live as a separate package.

Once there is a proof of concept, I can add chunked/paginated versions of the methods that return iterables (e.g. get_feeds, get_entries); I held back on this because I didn't really have a use case until now.

Thank you for your interest!

[clemera]

Thanks for the link! I will start with the simplest thing I can get to work, I'm a beginner with this so don't expect to much. If I have something useable I will post here to let you know and you can think about using it. Being able to pass an offset and a limit as url parameters would be very useful for me I don't know what else, I will have to experiment a bit :)

[lemon24]

No worries! :) Again, thank you!

---

Being able to pass an offset and a limit as url parameters would be very useful

The current implementation (not exposed in the public API) uses scrolling window queries instead of limit+offset, for performance reasons.

So, where a limit+offset API would look something like:

get_page_of_things(..., limit=20, offset=0*20) -> [1, 2, ...]
get_page_of_things(..., limit=20, offset=1*20) -> [21, 22, ...]

... the reader API will look like:

get_page_of_things(..., limit=20, next=None) -> ([1, 2, ...], 'next blob')
get_page_of_things(..., limit=20, next='next blob') -> ([21, 22, ...], 'another next blob')

where 'next blob' is an opaque string you pass to the function to get the next page.

This has the downside of not being able to go to the nth page directly, but this functionality can be added later if needed.

[clemera]

Thanks for your help, I don't think I would have a need to go to the nth page so this should work nice for my purposes. Currently I'm drawn into creating a generic tree UI builder for Emacs after which I plan to use it to implement the feed reader UI so it will take a while until I 'm able to start working on this. I will probably try to model the API similar to the miniflux API.

[lemon24]

Hi @clemera, pagination is finished now, and should be released in 1.12 in the following days. You can find a short description of how it works here: https://reader.readthedocs.io/en/latest/guide.html#pagination

[clemera]

Thanks for the notification! It currently busy with other projects but I'm still interested in this!

[lemon24]

I continue to not have enough bandwidth to implement/maintain a REST API, so I'm closing this for now.

If anyone wants to take on this work, or is willing to pay for it (I can offer commercial support), please re-open the issue. Thank you!