Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do you really know why you prefer REST over RPC?

apihandyman.io

Post reply on HN
Print view View original

51–60 of 124 posts

Re: Do you really know why you prefer REST over RPC?

#51

Post by rojoca »

k__ wrote: post #4
ams6110 wrote: post #2

I don't think GETs should ever change state. I'm fine with all other operations being POSTs though. If nothing else it provides compatibility with clients that don't support all the HTTP verbs (yes there are some)

How do you manage big queries with GET?

Usually used for long running queries but sometimes appropriate for this problem is creating a "query" resource via POST after which you have a URI for the results:

  POST /queries
  
  {"query": "..."}
  
  201 Created
  Location: /queries/1001
GET the results:

  GET /queries/1001
  
  {"results": ...}
You could optionally return results in the POST response too but I'm unsure whether that strictly conforms to the HTTP spec or not.

Re: Do you really know why you prefer REST over RPC?

#52

Post by sixdimensional »

DrJokepu wrote: post #6

But REST is RPC. I've read the article and the author basically defines RPC as a HTTP API that doesn't use the HTTP methods in a semantically correct manner but that's not what RPC is. RPC is any remote procedure call. It doesn't even have to be HTTP-based. Message queues are an example of something that's not RPC.

I agree with you. Too many get carried away with REST and don't think beyond HTTP.

I do appreciate the author's work here, I think the author was trying to help people clarify that REST/RPC don't need to be exclusive and that is helpful. All too often we encounter developers who want to sound smart and cool and state that it is "this tech" or "that tech" or NOTHING!

At a higher level of abstraction, representational state transfer should have nothing to do with HTTP semantics. It just so happens that we attribute REST with being related to HTTP semantics. But you could do REST with a non-HTTP protocol, if you wanted, why not?

Similarly, you can use a non-HTTP protocol in any other kind of framework for network based communication that you wanted...

And it just so happens that RPC is exposing functional, encapsulated units of code via network protocols and TCP/UDP sockets.

I remember trying to write my own network protocols for fun before over TCP and UDP sockets. Simple things like an echo service or a simple client/server application protocol. Doing that helps give one context for REST, RPC, SMTP, FTP, and more - semantics, concepts and frameworks over network connectivity.

The OSI model still matters. http://en.wikipedia.org/wiki/OSI_model

Re: Do you really know why you prefer REST over RPC?

#53

Post by NateDad »

REST is great for CRUD, and easy from javascript/web pages, but it sucks for non-CRUD actions (like logout a user or reboot a machine), and it is not as friendly as RPC for consuming from client libraries.

I have designed both, and I find that the contortions you have to do to make your API RESTful is generally not worth it unless you're almost entirely CRUD and are mainly targeting the browser (and even then, you probably have a lot more nonCRUD actions than you think).

For everything else, RPC wins because you design it much like regular code.

Maybe the answer is just to use both, rather than trying to jam a square peg in a round hole.

Re: Do you really know why you prefer REST over RPC?

#55

Post by marcosdumay »

smacktoward wrote: post #21
mpdehaan2 wrote: post #5

I started developing network apps before REST existed -- probably like many people here, that wasn't long ago, SOAP, various things like RMI and then XMLRPC were things. SOAP was never good anyway, deeply buried in standards committee goo. But there are still things I miss from these things. When I found XMLRPC after doing all these things, it was very much a "WOW" moment. (JSON of course, with it's definite differen…

> SOAP was never good anyway, deeply buried in standards committee goo. IMO SOAP in its very early days was actually fairly pleasant, at least when compared to the existing alternatives (things like COM and CORBA, which, ew). XML-RPC was also nice, in a "keep it simple, stupid" kind of way. Then of course SOAP crushed XML-RPC, the crew of the USS Enterprise got their hands on it, and the rest is (depressing) history.

I've met SOAP when IBM was already pushing it, thus I may have completely missed the early days.

But I never even imagined I'd hear somebody say SOAP was more pleasant than CORBA. Yes, working with is CORBA barely better than hitting your foot several times with a hammer, but relative to SOAP, it's a breeze.

Anyway, it's kind of depressing that even now the best RPC we have to show is REST. It's a problem that looks so simple from a distance, why can't somebody build something really great here?

Re: Do you really know why you prefer REST over RPC?

#56

Post by 3pt14159 »

bluepnume wrote: post #20

I generally use a pattern like: GET /api/resource POST /api/resource/action Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.

Why would you do this? It makes no sense.

By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.

Re: Do you really know why you prefer REST over RPC?

#57

Post by marcosdumay »

ams6110 wrote: post #2

I don't think GETs should ever change state. I'm fine with all other operations being POSTs though. If nothing else it provides compatibility with clients that don't support all the HTTP verbs (yes there are some)

Yes, just don't break HTTP.

Don't let GETs edit data, if you use PUT make sure it's idempotent, DELETE looks dangerous, be sure not to waste that, and do whatever you want with POST.

Re: Do you really know why you prefer REST over RPC?

#58

Post by jameshart »

eyko wrote: post #43
happyshadows wrote: post #24

Earlier quoted context omitted.

This is my approach as well. Works very well with an event-sourcing model. It is much easier to capture user intent with POST /api/customer/1/change-address-due-to-move { "address_1": "...", "address_2": "...", ... } than with: PUT /api/customer/1 { "address_1": "...", "address_2": "...", ... } Also, GET /api/resource/action is nice place for a payload describing the expected inputs to the action. Link it all togethe…

Why not PATCH /api/customer/1 {"address_1": "...", "history": "moved", ...} (i.e. send your intent as a parameter that may not necessarily get saved in this resource)

Because now your client needs to know what parts of the object need to be updated when a customer moves, and explain to the server exactly what those changes should be; and the server has to know how to validate that the client made a valid set of changes to the customer object.

If you instead have the client tell the server what kind of change you want to make, and provide the parameters to the operation, the server can do everything that needs to be done and the client doesn't need to care.

Re: Do you really know why you prefer REST over RPC?

#59

Post by rozap »

xrstf wrote: post #22

One point of doing REST instead of RPC is because you shouldn't re-invent the wheel. HTTP already has verbs and identifiers, so why create another set of verbs (the RPC methods)? REST is embracing HTTP to its fullest, RPC[overHTTP] is "just" taking advantage of HTTP's ubiquity across platforms. [Edit: I don't mind having a few RPC-style endpoints in a REST API. The world's not a perfect square and sometimes things ju…

REST is a subset RPC. There is no instead.

Re: Do you really know why you prefer REST over RPC?

#60

Post by amorphid »

wampus wrote: post #38

Is it correct to say that POST is not idempotent? Sometimes it is, and sometimes it isn't. Maybe it would be more accurate to say there's no guarantee that it's always idempotent.

POST is not idempotent. If you fill out a form, submit it, hit back, and submit again, if the form uses POST, each submission may be processed separately.
Post reply on HN