Yeah, I'm saying that you shouldn't have to think of such things like URL mapping. What if now all of sudden you want to post json as a filter? You will have to start thinking of new arbitrary ways to handle this query etc. You have to both parse this new deep nested filter you thought of in backend and also you have to stringify it in the frontend. You add so much extra overhead to try to convert the query into some form of string URI that would adhere to URL rules.

Let's say you now want to add a filter for frontend where you can choose multiple dynamic fields and their conditions can be either greater than, equal, or IN some values, I think you get the gist.

You then will have to do it something like that tasks?status=in:todo,progress

Or status=todo&status=done But then you suddenly need greaterThan query. Are you going to do tasks?priority=gt:5 for example?

Or things like that. And you have to worry if this even adheres to URL standards. Things eventually get so messy. And you are very constrained in everything you do.

And how do you typecheck all of that? Also all of this is just error prune, you have to write documentation for it and every REST api is a little bit different, people often mess up when naming the urls etc.

> Yeah, I'm saying that you shouldn't have to think of such things like URL mapping. What if now all of sudden you want to post json as a filter? You will have to start thinking of new arbitrary ways to handle this query etc. You have to both parse this new deep nested filter you thought of in backend and also you have to stringify it in the frontend. You add so much extra overhead to try to convert the query into some form of string URI that would adhere to URL rules.

I’m not sure I even follow what you’re proposing. That URLs are insufficient for nested structural queries or that you want URL queries and POSTed JSON queries (which is not even REST) at the same time?

If it’s the former, this isn’t something a client or server should need to worry about. Server tools should make defining the API simple in the native language, and generate documentation which can provide client SDKs (again I’m building such a tool).

> Let's say you now want to add a filter for frontend where you can choose multiple dynamic fields and their conditions can be either greater than, equal, or IN some values, I think you get the gist. [...] status=in:todo,progress [...] status=todo&status=done

The most common way this is handled is either your second syntax or status[]=todo&status[]=done (or even with explicit indexes) to make clear it’s multiple values. AFAIK most major URL (de)serializers handle this automatically with no developer effort.

> priority=gt:5

Why not priority=>5? Again a library can trivially handle simple expressions like this, you don’t have to.

> And how do you typecheck all of that?

This is something the library should handle too. And it’s something I know about because I’ve built it (and again I’m working on one I can make open source). For a hint of how this might look and some prior art, check out io-ts.

> Also all of this is just error prune, you have to write documentation for it and every REST api is a little bit different, people often mess up when naming the urls etc

I bet you can already predict it, but the library should take care of this and I’m building it.

None of this should be so messy or so much work for people developing services. You got that right! But that doesn’t mean REST is bad, it means the tools for building and consuming REST services aren’t very mature. But they certainly can be.