12 ms·

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

by pixie_ 14y ago

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 course" } Improved version: POST /course/UpdateDescription { courseId: 324234, description: "This is a level 2 course" } In this case POST is always used for api calls. Course is the namespace, UpdateDesciption is the method name, and parameters are kept all together as JSON.

scanr 14y ago
Here's where I've found REST very useful: It makes for predictable APIs for consumers and it means API producers have a checklist of things to implement to consider their interface 'complete'. It also provides a consistent way to think about how to expose an interface (or in fact, how to expose entities).
biot 14y ago
If your course has 20 member variables, now you have 20 update methods? If you want to update multiple, the client then needs to do multiple round-trip calls to your API which is time-consuming: if it's a 350ms round-trip per call, updating all 20 fields takes 7 seconds. And unless you go out of your way to offer per-object locking (which over a stateless connection has its own challenges) you prevent users from doing atomic updates to multiple fields at once. This pushes any rollback mechanism onto the client, exactly where it should not be. With your design, if your goal is to "combine all the parameters in one place to keep things simple", you could go one step further and have: POST /course/update {courseId: 1234, field: "description", description: "hello"} Taking this to its logical extreme, you can truly combine all the parameters in one place: POST / {object: "course", operation: "update", courseId: 1234, field: "description", description: "hello"}
- pixie_ 14y ago
  Like any other programming language if you need to update multiple fields, you pass multiple parameters to the function. The URL should be equivalent to namespace/class/method while the parameters are just that - parameters you can pass in JSON format.
  - MatthewPhillips 14y ago
    You're putting the burden of learning implementation details of your system onto your customers. That won't be comfortable for either them or you. Should you need to deprecate a method you'll never be able to remove it. So be prepared to write a lot of { "Error": "ErrorCodeThatOnlyMakesSenseInTheContextOfThisAPI", "Description": "DEPRECATED" }
jaimebuelta 14y ago
REST makes useful to be able to do: - UPDATE/course/324234 - GET /course/324234 - DELETE /course/324234 with predictable results. Of course, it works better when you have a clear hierarchy of resources, and/or it make sense to do UPDATE/GET/DELETE to the resources with clear results. I think it works for some cases very well, but I don't think is always the way to go. That said, there are a sensible number of "RESTful APIs" that are not RESTful at all, they just uses HTTP.
benatkin 14y ago
> 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?
- makmanalp 14y ago
  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.
  - josephlord 14y ago
    You missed: gets through proxies and firewalls. Unless that is what you mean by (b).
vyrotek 14y ago
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 http://www.jsonrpc.org/specification
enjo 14y ago
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?
- pixie_ 14y ago
  Just because something is GET doesn't mean it can be cached. It's not consistent, and every API call needs to be evaluated individually. The thing with REST is that it treats all functions as a variant of a CRUD operation, while functions may do more than just CRUD or a combination of CRUD operations in a single API call. Imagine if all your javascript functions had to be prefixed with GET/UPDATE/DELETE/etc.. you would feel constricted, and for what reason? Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete().
  - enjo 14y ago
    GET requests, by definition, should have no side-effects. Which makes them cacheable. Many browsers cache GET requests by default unless cache-control tells them not to. You can most definitely write a GET request that contains side-effects, but that's because you're doing it wrong (tm). Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete(). That's not data, that's an object. "MyCourse.32423" is the actual resource. It would actually look something more like: MyCourse32423.Delete(); Which seems pretty reasonable to me if we're trying to map this into programming language semantics (which I'm not even sure we should be doing).
smacktoward 14y ago
Congratulations, you just invented JSON-RPC (http://www.jsonrpc.org/ http://www.jsonrpc.org/).
- pixie_ 14y ago
  I'm not saying how the parameters or return values should be formatted other than the fact they're in JSON format. JSON-RPC requires you to conform to their specifications.
  - bct 14y ago
    APIs that ignore the realities of distributed computing and that each have different special-snowflake wire formats requiring tedious documentation: the worst of both worlds.
    - pixie_ 14y ago
      I'm not arguing against implementing an RPC if that's what you need. My original post describes a super set of JSON-RPC.
      - drivebyacct2 14y ago
        Your post implies a pseudo-free-for-all and defeats the purpose of having a conversation about a standard exchange format. You basically have said "I want to make it work the way I want it and I don't care if it's non-standard and unintuitive.". You're welcome to do that, but everyone who needs to work with it will hate you. And when you've been working on it for 2 months, or take a two month break, you'll come back and hate yourself too...
mixedbit 14y ago
IMO the biggest benefit of REST vs RPC is reduced coupling between the client and the server. With RPC client needs to be explicitly aware of all methods and parameters that the server supports. With well designed REST interface this is not the case, you can have a generic client that does not need to be explicitly coded to support the specific service. REST interfaces are more difficult to design than RPC interfaces, but they are also more elegant and simpler. Roy Fielding (REST father) argues that elegant and simpler != easier.
- politician 14y ago
  Rich Hickey (Clojure) has a presentation about the differences between simple and easy. If you have the time, it's worth it. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
bct 14y ago
> Making a call to a server should be like calling a function anywhere else You can make calling a function on a remote machine look and seem (superficially) like calling a local function, but they will never have similar behaviour. A network is very different from a motherboard. http://www.tbray.org/ongoing/When/200x/2009/05/25/HTTP-and-the-Fallacies-of-Distributed-Computing http://www.tbray.org/ongoing/When/200x/2009/05/25/HTTP-and-t...

by pixie_ 14y ago

scanr 14y ago

Here's where I've found REST very useful: It makes for predictable APIs for consumers and it means API producers have a checklist of things to implement to consider their interface 'complete'. It also provides a consistent way to think about how to expose an interface (or in fact, how to expose entities).

biot 14y ago

If your course has 20 member variables, now you have 20 update methods? If you want to update multiple, the client then needs to do multiple round-trip calls to your API which is time-consuming: if it's a 350ms round-trip per call, updating all 20 fields takes 7 seconds. And unless you go out of your way to offer per-object locking (which over a stateless connection has its own challenges) you prevent users from doing atomic updates to multiple fields at once. This pushes any rollback mechanism onto the client, exactly where it should not be. With your design, if your goal is to "combine all the parameters in one place to keep things simple", you could go one step further and have: POST /course/update {courseId: 1234, field: "description", description: "hello"} Taking this to its logical extreme, you can truly combine all the parameters in one place: POST / {object: "course", operation: "update", courseId: 1234, field: "description", description: "hello"}

pixie_ 14y ago
Like any other programming language if you need to update multiple fields, you pass multiple parameters to the function. The URL should be equivalent to namespace/class/method while the parameters are just that - parameters you can pass in JSON format.
- MatthewPhillips 14y ago
  You're putting the burden of learning implementation details of your system onto your customers. That won't be comfortable for either them or you. Should you need to deprecate a method you'll never be able to remove it. So be prepared to write a lot of { "Error": "ErrorCodeThatOnlyMakesSenseInTheContextOfThisAPI", "Description": "DEPRECATED" }

jaimebuelta 14y ago

REST makes useful to be able to do: - UPDATE/course/324234 - GET /course/324234 - DELETE /course/324234 with predictable results. Of course, it works better when you have a clear hierarchy of resources, and/or it make sense to do UPDATE/GET/DELETE to the resources with clear results. I think it works for some cases very well, but I don't think is always the way to go. That said, there are a sensible number of "RESTful APIs" that are not RESTful at all, they just uses HTTP.

benatkin 14y ago

> 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?

makmanalp 14y ago
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.
- josephlord 14y ago
  You missed: gets through proxies and firewalls. Unless that is what you mean by (b).

vyrotek 14y ago

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 http://www.jsonrpc.org/specification

enjo 14y ago

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?

pixie_ 14y ago
Just because something is GET doesn't mean it can be cached. It's not consistent, and every API call needs to be evaluated individually. The thing with REST is that it treats all functions as a variant of a CRUD operation, while functions may do more than just CRUD or a combination of CRUD operations in a single API call. Imagine if all your javascript functions had to be prefixed with GET/UPDATE/DELETE/etc.. you would feel constricted, and for what reason? Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete().
- enjo 14y ago
  GET requests, by definition, should have no side-effects. Which makes them cacheable. Many browsers cache GET requests by default unless cache-control tells them not to. You can most definitely write a GET request that contains side-effects, but that's because you're doing it wrong (tm). Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete(). That's not data, that's an object. "MyCourse.32423" is the actual resource. It would actually look something more like: MyCourse32423.Delete(); Which seems pretty reasonable to me if we're trying to map this into programming language semantics (which I'm not even sure we should be doing).

smacktoward 14y ago

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

pixie_ 14y ago
I'm not saying how the parameters or return values should be formatted other than the fact they're in JSON format. JSON-RPC requires you to conform to their specifications.
- bct 14y ago
  APIs that ignore the realities of distributed computing and that each have different special-snowflake wire formats requiring tedious documentation: the worst of both worlds.
  - pixie_ 14y ago
    I'm not arguing against implementing an RPC if that's what you need. My original post describes a super set of JSON-RPC.
    - drivebyacct2 14y ago
      Your post implies a pseudo-free-for-all and defeats the purpose of having a conversation about a standard exchange format. You basically have said "I want to make it work the way I want it and I don't care if it's non-standard and unintuitive.". You're welcome to do that, but everyone who needs to work with it will hate you. And when you've been working on it for 2 months, or take a two month break, you'll come back and hate yourself too...

mixedbit 14y ago

IMO the biggest benefit of REST vs RPC is reduced coupling between the client and the server. With RPC client needs to be explicitly aware of all methods and parameters that the server supports. With well designed REST interface this is not the case, you can have a generic client that does not need to be explicitly coded to support the specific service. REST interfaces are more difficult to design than RPC interfaces, but they are also more elegant and simpler. Roy Fielding (REST father) argues that elegant and simpler != easier.

politician 14y ago
Rich Hickey (Clojure) has a presentation about the differences between simple and easy. If you have the time, it's worth it. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

bct 14y ago

> Making a call to a server should be like calling a function anywhere else You can make calling a function on a remote machine look and seem (superficially) like calling a local function, but they will never have similar behaviour. A network is very different from a motherboard. http://www.tbray.org/ongoing/When/200x/2009/05/25/HTTP-and-the-Fallacies-of-Distributed-Computing http://www.tbray.org/ongoing/When/200x/2009/05/25/HTTP-and-t...