REST is like set of best practices to design API end points like define resource as end point and map standard HTTP methods to certain operations. This makes it easy and leads to a standard in API designing. And underlying technology can be RPC or servlets too. For example define end point "/user" and client knows how to create update or delete user where as before Rest these used to be different end points for each of these operations or have to specify the kind of operation
More like set of worst practices. You have some API exposed in plenty of
endpoints instead of one, and on top of that you embed one of the call
arguments in the URL itself.
And no, it doesn't make designing API easier if you preallocate "read",
"create", and "delete" operations to separate HTTP methods, and then put
all the other operations in POST. "Create" and "delete" in many cases don't
even make any sense to guarantee their being specially distinguished.
And you say that RPC can be used under REST. Do you have any example of
a REST client library that actually can do that? It's the first time I ever
hear about this way. Almost everybody else uses REST like an underspecified
RPC protocol, cramming call request into an ad-hoc JSON structure to HTTP POST
and mixing error reporting from transport layer and from application.
You're wasting your breath. REST zealots will never be convinced that anything other than the magic four of GET / PUT / POST / DELETE is necessary.
It's like someone advocating writing all software should be written in Brainfuck, because the cognitive load of remembering eight operators is so much easier than learning all these keywords and syntax and runtime libraries that come in other languages. Except whereas our imagined Brainfuck advocate would be rightly ignored, REST has somehow become the fucking dominating paradigm of our industry.
The idea that reduced complexity in one area might trade off with much greater complexity in another simply does not wash with these people. They have a resource & verb shaped hammer, and they are going to use it to batter each and every API into some kind of nail shape, no matter the effort it takes and the carnage that ensues.
Well there are no hard and fast rules. Any set of best practices are opinionated. You can have different of opinions if they are not suited for your use case. All the REST frameworks you found are designed around the those ideas. For making your APIs rest you do not need any framework you can design your APIs along those guidelines. Again how far your apis need to be REST complaint again it is upto common sense.
"Best practices" are supposed to work sensibly in most cases. REST only works
in a small subset (read/create/delete and nothing more), other cases being
stuffed collectively under HTTP POST umbrella, so you need some RPC protocol
anyway. This is very far from working sensibly.
I agree. A lot of "normal" operations that need to be implemented usually perform actions to different tables/entities. So, the accepted "REST" way of doing things forces you to either move your combination/"atomicity" logic to the frontend, or to call other REST actions from the first rest call itself. Even then, that specific call is not linked to an entity, but stands on its own.
