def handle_thing(thing):
r = urllib.request.Request(url='example.com',
data={'stuff': 1})
return urllib.request.urlopen(r)
Just one example.
I know the tooling has improved somewhat since REST has become extremely common, so this is less of an issue now than it used to be (for example, most people use the Python requests module now, which makes it harder to use the wrong method (though many other HTTP libs still have the older urllib-style design)), but it's still annoying in principle. Combine with the fact that people tend to have different ideas about what the HTTP verbs and response codes mean, and it's pretty yucky.
Compare with Thrift, where you define an interface, list the possible exceptions, and generate stubs that auto-handle all of this communication exchange for you. All you have to do is make sure that you're calling the correct function, which should be pretty obvious.
This differs from setting the correct method in the HTTP headers in a couple of ways: first, HTTP clients usually assume a default method of GET. With a different protocol, there is no default "method", your action has to be defined somewhere. There will be no assumption (unless you code something implicit like this on top).
Second, a more conventional method has increased code locality, meaning the code that affects the operation is likely to be in the same source file/area. You'll normally be calling an ordinary function name like SaveThing inside the application logic flow, and it will be easier to debug, easier to realize the problem, etc.; the operation to perform is not tucked away in some other contraption that affects the headers.
Is it possible to design REST codebases so that such errors are hard to cause? Sure. But why do it the REST way and make it harder on yourself?
It should be just as easy to see what function you're asking the API to perform on a resource as it is to see what you're sending it. The operation I want to perform is an intrinsic part of what I'm doing. There's no reason to separate it and make it hard. I'd even prefer url-based actions, like example.com/string_save, because then at least the resource and operation are defined in the same spot.
A simple JSON envelope that has an "operation" key separate from a "data" key would make this easy, but then it's not in your header anymore, so it's not "real REST".
>You're going on about the value of "conventional methods" in a criticism of using HTTP verbs?
Yes? These have some intrinsic value that is defined in the domain. There is no potential of vocabulary contamination because everyone comes into the domain with a clean state. An ambiguous, abused common vernacular is worse than a clean domain-specific one.
>Understanding the difference between a GET and a POST isn't some new-fangled idea, it's decades old. Like Tim Berners Lee old.
GET and POST usually work out OK; it's stuff like HEAD, PUT, and PATCH that people usually argue about, not to mention response codes.
GET, POST, and the HTTP intricacies are fine as a concern for HTTP clients. REST has shot through that and made it something that everyone has to worry about.
The issue is not only that no one can agree on how to do REST, but it's also, as stated in my other comment, that REST makes it harder to see what's going on. It requires important information (the verb) to be tucked away into something that takes extra steps to access. I'm not saying it's impossible to access that; I'm just saying it's error prone to do it this way.
>I didn't even know what Thrift was until I Googled it, and found out it was developed at Facebook. Okay.
I hate most "Project-By-BigCo" projects, but not everything that comes out of Google or Facebook is automatically evil.
Thrift is now controlled by the Apache Foundation, not Facebook. And it's a very common IDL, but I'll refrain from returning your snark. ;)
>I'm stunned. Do you write code that runs on the internet?
The edit timeout is expired on my other comment, but it just occurred to me that, since you were unfamiliar with what is arguably the most-used IDL today, you may not understand that interface definition language like Thrift defines the interface, not just the objects. You'll have a section like (adapted from the Apache Thrift tutorial file [0])
which lists the method name, parameters and types, return type, and possible exceptions. The objects are defined elsewhere in the file (or in an include). The method name is not just a value that is randomly assigned by the developer (and how could it be? the interface has to name the things so they can be referenced).
To be a firm REST religionist, as you seem to be, you must not have worked with it very often, but you can see that an actual IDL, and Thrift is just one of several, would make things much easier than the loose "My REST is purer than your REST" dick-measuring contests.
I know the tooling has improved somewhat since REST has become extremely common, so this is less of an issue now than it used to be (for example, most people use the Python requests module now, which makes it harder to use the wrong method (though many other HTTP libs still have the older urllib-style design)), but it's still annoying in principle. Combine with the fact that people tend to have different ideas about what the HTTP verbs and response codes mean, and it's pretty yucky.
Compare with Thrift, where you define an interface, list the possible exceptions, and generate stubs that auto-handle all of this communication exchange for you. All you have to do is make sure that you're calling the correct function, which should be pretty obvious.
This differs from setting the correct method in the HTTP headers in a couple of ways: first, HTTP clients usually assume a default method of GET. With a different protocol, there is no default "method", your action has to be defined somewhere. There will be no assumption (unless you code something implicit like this on top).
Second, a more conventional method has increased code locality, meaning the code that affects the operation is likely to be in the same source file/area. You'll normally be calling an ordinary function name like SaveThing inside the application logic flow, and it will be easier to debug, easier to realize the problem, etc.; the operation to perform is not tucked away in some other contraption that affects the headers.
Is it possible to design REST codebases so that such errors are hard to cause? Sure. But why do it the REST way and make it harder on yourself?
It should be just as easy to see what function you're asking the API to perform on a resource as it is to see what you're sending it. The operation I want to perform is an intrinsic part of what I'm doing. There's no reason to separate it and make it hard. I'd even prefer url-based actions, like example.com/string_save, because then at least the resource and operation are defined in the same spot.
A simple JSON envelope that has an "operation" key separate from a "data" key would make this easy, but then it's not in your header anymore, so it's not "real REST".