Hacker News Reader

Comment by zimbatm | Hacker News Reader

You have variants in: the HTTP method, the URL path, the URL query params, various HTTP Headers (cookie, content-encoding, content-language, ...), the Body (with various forms of content encoding) , did I miss something ?

If you think of a request as a function call then it's all parameters and it's completely crazy.

View on HN

Yup. That's why requests aren't function calls. REST is a different architecture than RPC, which is why you need all of these conventions to do RPC over HTTP: you're mapping one architecture onto another.

A HTTP request is a function call. A function call is message passing. No matter if you use RPC, SOAP or what not. It's conceptually all the same - the caller sends a message to the callee which responds with another message.

Yes, if you map the concepts over. Which is what you just did. The RESTful architecture is explicitly _not_about function calls. It's about manipulating state diagrams. Yes, you do that through a message, but it's different than a function call, unless you define 'function' and 'message' in a way that's completely meaningless. If any message is a function call, a UDP packet is a function call.

alphadogg, you have been hellbanned for more than 2 years.

At this point, I'd just like to inject that looking anything across a network as a function call is probably not a good idea.

Yes, RESTful requests end up in a big-ass state machine like that: https://raw.github.com/wiki/basho/webmachine/images/http-hea... It's great because it allows for a great diversity of clients. In exchange the system is much more complex.

If you can require your client to behave in a normalized way then all this complexity is not necessary and you're probably avoiding some bugs along the way.

Yup, there's that one, but it also means that you model your application logic as a state machine...

Reply on news.ycombinator.com