[tuespetre]

When do you need to get a list like that where they couldn’t be collectively addressed by some other resource identifier? If we treat our “REST APIs” as generic database interfaces instead of equipping them with more semantics, of course we hit that wall.

[leeoniya]

if a user selects a bunch of options and records in the interface and then wants to pull an aggregate report on specific items which would translate into some AND id IN (...).

what if you need to delete a bunch of specific records in a single HTTP request with REST? you're fucked. DELETE is designed to deal with one record at a time [1]. sure, DELETE could have a body, but the recommendation is to ignore it [2].

to operate on multiple specific records, you're stuck doing at least 2 requests. a POST that asks the server to create some temporary "collection" record. and then use the new URI of that collection to perform more operations. why do all this overhead when you can just do the delete operation with a POST request and a body filled with record ids?

i could continue, but it should be obvious that REST was designed with the server as the center of the universe. when trying to shoehorn this worldview into modern fat clients and high-perf SPAs, it very quickly falls down.

[1] https://www.restapitutorial.com/lessons/httpmethods.html#del...

[2] https://stackoverflow.com/questions/299628/is-an-entity-body...

[dsego]

I don't think POST-ing to a /delete-records resource goes against REST, the original one, not the “common” one.

[sopooneo]

That's an interesting idea I hadn't ever thought of. But would such an endpoint return anything meaningful on a GET request? Would it return a list of all deleted records?