Hacker News Reader

Comment by peterwwillis | Hacker News Reader

This is a well-written and informative article, kudos.

That said, it reminds me how fucking overcomplicated REST HTTP API is for 99% of uses. As an API user, all I want is to call a function on a server, pass it some arguments and get a result. I want it to be dead simple, and REST is probably the opposite of that.

Finally, it also occurs to me that most API calls may call one function which returns lots of data that I don't need. Specifying the data types and field names I want in the query would simplify parsing and potentially reduce bandwidth use (if you've ever seen an API call that returns a user's profile when all you wanted was their last login timestamp, you know what I mean). edit Whoops, didn't see he mentioned the field limiter... why don't more people do that?

View on HN

REST only looks complicated because you're seeing it with RPC goggles. In REST, you don't call functions, you just ask for documents and send documents to the server(s). There's nothing particularly complicated in it, it's just a different approach.

That said, this article isn't particularly faithful to REST.

I guess the way I think of REST is that you make requests of different kinds to resources, some of the responses containing documents that contain references to other resources - and all you need to start is the "root" document for the service and an understanding of what the contents of each document mean.

Sure, but peterwwillis was likely making the point that REST sometimes just gets in the way. REST itself is not complicated, but trying to make it work where it shouldn't can complicate what you're trying to do. Not all APIs can be modeled well with the "resource" or "document" concept. A lot of times all you really want is to ping an endpoint and get/post some data.

If you just want to get/post some data, why are you modeling the system using functions (computations)? If anything, a document oriented approach is much more suited for that use case.

Sorry. I shouldn't have over simplified that point about it being just data. I meant to emphasize that you really want to just call an operation and "just do some work". The data being just function parameters with optional data returned.

I'm currently working on a few large B2B APIs and it's been difficult to implement REST. The value of these APIs come from the actual work performed and not just updating the state of a few rows in a DB. I have very "business logic" heavy endpoints which take many parameters and return very different payloads. As much as I hate it, sometimes business and practicality comes before purity. :)

I actually asked for some feedback in a comment below buried somewhere: https://news.ycombinator.com/item?id=5819821

Oh no, I certainly don't think there's anything wrong or impure about not implementing REST. REST is an architectural style that, by imposing some constraints, gives you certain benefits (Fielding's paper talks about this). It's not a panacea, and it's certainly not right for every case.

Just don't make an RPC API and call it RESTful ;)

I fully agree. Fielding warns in his dissertation about design by buzzwords himself.

Almost all web APIs out there aren't REST APIs because they don't respect the "driven by hypermedia" constraint which makes sense because this constraint was put in place for human users driving applications through web browsers, not for machines.

I've started to formalize a new "Web API" architecture style that takes the best of REST but leaves the requirements and constraints that don't make sense. See this blog post: http://blog.restlet.com/2013/05/02/how-much-rest-should-your...

Maybe HTTP is simply missing the INVOKE verb for executable documents.

Sounds good to me :)

That's already POST, basically.

Furthermore, if you really wanted to, HTTP does allow new verbs to be added, so...

If you want to retrieve some data based on some parameters, you can just GET it and pass some query strings. You shouldn't need to care if the data comes from an executable file (which is usually does anyway) or someone typing it in on a terminal.

It seems more complicated to me to define a document format that provides URLS, than to just tell people what the URLs are.

In my mind I think of some things e.g.: google search, as a function not a resource. Trying to think about what the resource might be seems tangential to what I am trying to do.

> As an API user, all I want is to call a function on a server, pass it some arguments and get a result. I want it to be dead simple, and REST is probably the opposite of that.

How is this not dead simple in REST? Can you provide a specific example and how REST makes it complicated? Because I don't see it.

I think you are confusing the qualities of a good public API and a good internal/private one (for application architecture purposes only.) For internal, I believe REST is the way to go, no contest. Externally is a different story. You would typically only expose a subset of functionality, use different authentication schemes and use a format that can be more easily accessed across domains like JSONP.

The problem with limit is the programming overhead in frontend and backend.

If you want a performance advantage you must parse the limit-params and select only the needed fields from db and send them to client. But this make the backend complicated.

If something is misspelled (frontend/backend) you need more time to find the error.

It is easier and cleaner provide some additional calls for specific data (like lastLogin).

If you use something like Backbone in frontend, you are happy to access all needed data so easy, why restrict them?

Ok if you have an heavy used performance critic application, you can start optimizing. But why, welcome to the cloud, add some processes ;-)

Reply on news.ycombinator.com