3 ms·

Microsoft-stack developer doesn't understand how HTTP works. Film at eleven.

by aaronem 12y ago

JohnDeHope 12y ago
I've been feeding my family and paying my mortgage using the Microsoft stack. God bless it. I also have never understood the REST mojo. I agree with the original poster. For my money, a url that resolves to a public API end point, with query string parameters to encode the arguments, is the most straightforward way to do RPC over HTTP I've used myself. When things get more complicated, as with an ajax client, then embedding JSON in the request body has also always worked well for me. Would straight up REST be better? Maybe, but I don't see it.
- aaronem 12y ago
  Hey, I didn't say anything against the Microsoft stack; I've made a living off it myself, at times, although mostly at a lower (i.e. VBA) level. But it doesn't really lend itself to easy understanding of REST. As far as REST vs. RPC goes, there is a sole essential difference: the semantics of interaction with a REST resource are defined in RFC 2616, and a correctly designed and implemented REST resource behaves in accord with what you find there. REST itself, meanwhile, being just HTTP, is very simple, and very well suited to expressing interactions with resources and collections of resources. Especially in the front-end/full-stack development world, most things can be expressed, with little or no semantic strain, as resources and collections of resources, and capable HTTP clients are highly available. (And the convention of encoding structured data as JSON in request bodies is very strong, besides.) Conversely, there are as many RPC-over-HTTP standards as there are implementations; since doing RPC over HTTP necessarily means mapping whatever semantics you have in hand to an interface not designed to express them well, this makes headaches for people who have to develop against them, especially when writing an application that draws together many disparate APIs in order to do something interesting at their conjunction. Whether REST is better than RPC over HTTP, or vice versa, strikes me as a question for a philosopher. But, in most cases of interacting with a remote resource over an HTTP transport, REST is certainly more natural, that is, closer to the native semantics of the transport, which results in thinner glue layers and more easily understood behavior.

Microsoft-stack developer doesn't understand how HTTP works. Film at eleven.

by aaronem 12y ago

Microsoft-stack developer doesn't understand how HTTP works. Film at eleven.

I've been feeding my family and paying my mortgage using the Microsoft stack. God bless it. I also have never understood the REST mojo. I agree with the original poster. For my money, a url that resolves to a public API end point, with query string parameters to encode the arguments, is the most straightforward way to do RPC over HTTP I've used myself. When things get more complicated, as with an ajax client, then embedding JSON in the request body has also always worked well for me. Would straight up REST be better? Maybe, but I don't see it.

aaronem 12y ago
Hey, I didn't say anything against the Microsoft stack; I've made a living off it myself, at times, although mostly at a lower (i.e. VBA) level. But it doesn't really lend itself to easy understanding of REST. As far as REST vs. RPC goes, there is a sole essential difference: the semantics of interaction with a REST resource are defined in RFC 2616, and a correctly designed and implemented REST resource behaves in accord with what you find there. REST itself, meanwhile, being just HTTP, is very simple, and very well suited to expressing interactions with resources and collections of resources. Especially in the front-end/full-stack development world, most things can be expressed, with little or no semantic strain, as resources and collections of resources, and capable HTTP clients are highly available. (And the convention of encoding structured data as JSON in request bodies is very strong, besides.) Conversely, there are as many RPC-over-HTTP standards as there are implementations; since doing RPC over HTTP necessarily means mapping whatever semantics you have in hand to an interface not designed to express them well, this makes headaches for people who have to develop against them, especially when writing an application that draws together many disparate APIs in order to do something interesting at their conjunction. Whether REST is better than RPC over HTTP, or vice versa, strikes me as a question for a philosopher. But, in most cases of interacting with a remote resource over an HTTP transport, REST is certainly more natural, that is, closer to the native semantics of the transport, which results in thinner glue layers and more easily understood behavior.