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

When REST isn't Good Enough

braintreepayments.com

Post reply on HN
Print view View original

11–20 of 94 posts

Re: When REST isn't Good Enough

#11

Post by vyrotek »

pixie_ wrote: post #5

I don't like REST. Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves. It's a much better design to combine all your parameters in one place and keep things simple, for example - REST version: UPDATE /course/324234 { description: "This is a level 1…

I'm with you on this one. Don't get me wrong, I think REST is great too but mostly just because it's something we can agree on.

In the end a route/url maps to a method with parameters anyway. I wish JSON-RPC was a bit more popular. http://www.jsonrpc.org/specification

Re: When REST isn't Good Enough

#12

Post by jeremyjh »

Why not provide a C api? This would make it easy for community language bindings to capture the benefits you describe in languages you aren't natively supporting (such as Go, Erlang or Haskell).

Re: When REST isn't Good Enough

#13

Post by enjo »

pixie_ wrote: post #5

I don't like REST. Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves. It's a much better design to combine all your parameters in one place and keep things simple, for example - REST version: UPDATE /course/324234 { description: "This is a level 1…

The REST version makes it clear that you are dealing with operations on a resource. The URL identifies a thing in a consistent way, while the method and corresponding data allow you to manipulate it.

The biggest benefit comes when building a cache architecture. RESTful API's (when properly implemented) come with built-in assumptions about idempotency. You end up in a place where you can easily cache GET requests while reasoning in a very consistent way about where changes to a resource will be made.

It's a pattern that comes with a lot of really useful benefits.

Now all of those same qualities can be built into other architectural styles (such as the one you propose). However, I find that it becomes much harder to reason about the role of operations and what they're actually doing when you lose that clear distinction that REST enforces.

I do want to quibble with one thing as well:

In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves

That's true for any modular system isn't it? You have the object you are operating on, you have the operation, and you have the data. Object-oriented systems and even most structured languages (like Javascript for instance) make this distinction at some level. Why is that not appropriate for web architecture?

Re: When REST isn't Good Enough

#14

Post by arethuza »

davetron5000 wrote: post #2

This has been my approach to internal service design as well. It's far easier to make sure people integrate properly by providing a rich, well-documented API client library than it is to rely solely on the REST-based one. REST APIs are hard to document, and require a lot of orthogonal boilerplate to even make the requests properly. Making a client library is also a great way to "dogfood" your REST API - you know a de…

"require a lot of orthogonal boilerplate to even make the requests properly"

What kind of boilerplate would that be? For me one of the big advantages of a RESTful interface is that they are really easy to call from cURL without much need for building up a complex context.

Re: When REST isn't Good Enough

#15

Post by makmanalp »

benatkin wrote: post #9
pixie_ wrote: post #5

I don't like REST. Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves. It's a much better design to combine all your parameters in one place and keep things simple, for example - REST version: UPDATE /course/324234 { description: "This is a level 1…

> Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. What you've described is RPC, which has been around for ages. Why do you think REST became a popular alternative to RPC?

Because the de-facto transport for it is HTTP, which a) People know b) Is simple and predictable c) Has had support from every language on the face of the earth, for ages and thus d) Takes 1 minute to get up and running with, as opposed to, say, SOAP etc. e) Fits the CRUD model fairly nicely, which comprises the majority of web apps.

Nothing to do with one man's phd thesis or anything (that came YEARS after he wrote the HTTP spec and after most RPC systems). If I had a penny for all the theses that proposed something reasonable which was ignored.

Re: When REST isn't Good Enough

#16

Post by mikeknoop »

We (Zapier) are in a particularly good place to comment on this. We have implemented about 70 very diverse web APIs in-house. Early on, we used client libraries because they were easy and convenient. That decision bit us, hard. (Most) client libraries are un-maintained, opaque, and difficult to extend.

We spent many months ripping every client library out down to the raw requests. We are in a unique position because of how many APIs we have to support, but the overarching advise we give to people designing APIs:

If you are deviating from the norm, you're doing it wrong.

REST APIs are nice because you can infer how to communicate with the API out of the gate. APIs are a pain and you only introduce headaches by not doing things in a sane, conventional fashion.

Re: When REST isn't Good Enough

#17

Post by smacktoward »

pixie_ wrote: post #5

I don't like REST. Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves. It's a much better design to combine all your parameters in one place and keep things simple, for example - REST version: UPDATE /course/324234 { description: "This is a level 1…

Congratulations, you just invented JSON-RPC (http://www.jsonrpc.org/).

Re: When REST isn't Good Enough

#18

Post by e28eta »

arethuza wrote: post #14
davetron5000 wrote: post #2

This has been my approach to internal service design as well. It's far easier to make sure people integrate properly by providing a rich, well-documented API client library than it is to rely solely on the REST-based one. REST APIs are hard to document, and require a lot of orthogonal boilerplate to even make the requests properly. Making a client library is also a great way to "dogfood" your REST API - you know a de…

"require a lot of orthogonal boilerplate to even make the requests properly" What kind of boilerplate would that be? For me one of the big advantages of a RESTful interface is that they are really easy to call from cURL without much need for building up a complex context.

I found the translation between native code and a REST API to be what I'd call boilerplate. You need to build a URL, build the request (usually converting some model object into JSON), make the request in a non-blocking fashion, receive and parse the response into either a successful response, probably converting JSON back into a model object, or a failed response, which needs to be mapped to some native representation and passed back into the business logic.

Contrast that with a client library which can do all of that for you, for example: taking a native model object and calling one of two callback functions provided, letting you concentrate on the business logic of your app.

I'm not arguing that a client library is the right way to go, but I certainly understand where the grandparent is coming from RE: boilerplate code. Also, this is going to be heavily influenced by the language and libraries you're using.

Re: When REST isn't Good Enough

#19

Post by jeremyjh »

mikeknoop wrote: post #16

We (Zapier) are in a particularly good place to comment on this. We have implemented about 70 very diverse web APIs in-house. Early on, we used client libraries because they were easy and convenient. That decision bit us, hard. (Most) client libraries are un-maintained, opaque, and difficult to extend. We spent many months ripping every client library out down to the raw requests. We are in a unique position because…

Can you respond directly to some of the points raised in the article? For example, ensuring SSL certs are validated?

Re: When REST isn't Good Enough

#20

Post by outdooricon »

The platform support argument is not very persuasive here. The beauty of open source and the community is that when you combine a popular service with common platforms that are likely to be used, it is likely someone in the community will release the needed api. Why not provide some community support for the platforms, but allow the users to release an api where they know their needs better than you do?

On the other hand, the security argument is quite strong. Improperly implemented SSL handshaking, especially when dealing with payment transactions like they do, has the potential to be devastating. But this is where interacting with the community that is making the api's would be key. There's a lot of value to be had when company and community development work together. They could contribute the ssl code themselves to the open source client projects.

Post reply on HN