Rationale behind making API v2 endpoints POST only?

[shamoon]

Hey team, I’m one of the homepage devs where we have a little “widget” that integrates with komga.

I was looking at https://komga.org/docs/api/deprecation and noted the upcoming changes to eg api/v1/series, specifically that they are going to require a POST request.

I’m writing as I’m curious about this choice, I think it’s not so expected for a REST API endpoint that does not modify or really require any data. And of course I’m asking because it will require big-ish (bigger than most API changes) on our end as homepage intentionally tries to avoid making POST requests in its widgets.

Of course, we can deal with whatever, and it’s your project (duh), but thought I’d ask. Hopefully no offense is taken from the question (none intended).

Thanks

[gotson]

The new endpoint needs a request body, which by REST standards cannot be passed in GET endpoints. Many API tooling will not allow to pass a body to a GET request.

It's standard practice to use POST for such queries that require a request body.

I think there's a RFC to create a new QUERY HTTP method that would basically work like a GET, but with a request body, but that's not standard yet.

[shamoon]

Thanks for the reply.

I see. Why the requirement for a request body? It seems to work with an empty body. And in general, the params could presumably be passed as query params?

[shamoon]

Ah, I see it accepts complex queries. Maybe those could require a POST while simple listing with e.g. page, sort etc. params could be GET.

But yea, of course, your call.

Thanks