If your application needs so many objects at once, yes, then you probably need something else. Or you just abstract it away through some POST interface alongsid

If your application needs so many objects at once, yes, then you probably need something else. Or you just abstract it away through some POST interface alongside with the 10k resources. > There is no simple way to build transactions on top of REST so if you need to do something that involves updating more than one data record you really are best off updating them all in one API call. Yes, you can do that. I mean, if your really need to do that. Otherwise, your client should check the server resources for whether they represent to correct data. And you can always implement something like implicit transactions, where you create a transaction resource and append data to it or create new resources in a certain context. EDIT: BTW. You don't have to do everything in REST. You can always "upgrade your protocol". So having a link myrpc://myserver:port is very valid. > If Fielding's thesis went in the trash and got replaced with "one click, one API call, update the UI" we'd hear a lot less carping about how awful the web platform is. Then we would end up building clients that always implement 100% of your RPC API. And we would not be able to move resources around. Implementing clients and servers would become an all-or-nothing thing, which really bad. > Careful reading of the http spec is a road to hell anyway because 80% of it is dark corners that aren't really used or implemented. By that you mean, that YOU have only used 20% of the spec so far? So why is it bad in general? I did not see these dark corners.