|
> Before HTTP, people were already long doing RPC using e.g. DCOM, CORBA,RMI, etc. Reinveinting RPC over X has been the fate of pretty much every way we've come up with to make two computers talk to each other. The key difference between Representational State Transfer and RPC, which makes all of the other capabilities of REST possible, is: REST deals with nouns and uses HTTP verbs (the common ones, or you can invent your own) to handle a specific and common grammar of operations against those verbs: POST _hyn3 > /user # (C)reate
GET /user/_hyn3 # (R)ead
PUT /user/_hyn3 # (U)pdate
GET /users < _hyn3 # List
DELETE /user/_hyn3 # (D)elete
RPC was literally "remote procedure call", which means you're calling a remote verb and then specifying your noun as an argument or data: POST _hyn3 > /users/create_user
GET /users/get_user/_hyn3
POST /users/update_user/_hyn3
GET /users/list_users < _hyn3
POST /users/delete_user/_hyn3
It's more than just semantics, because it gave a common language for almost all CRUD type operations. (Thus, even though REST was never about CRUD, as the titular article states, CRUD and REST do have a lot in common, because CRUD represents an extremely common data access pattern and common HTTP verbs, if not REST itself, map to it very cleanly and nicely.)In other words: REST deals with HTTP and the facilities that it provides. It doesn't directly with the verbs behind HTTP, such as GET/PUT/DELETE/etc. It instead provides an architectural paradigm shift, in which the URL itself is a discrete representation of the data in question, and the verbs -- RPC's -- are just standardized ways of dealing with that data. This seemingly simple change, obvious only in hindsight, set the stage for a massive change in how API's are produced and consumed. |