Comments on: Convenience Over Correctness http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ Ask forgiveness, not permission. Fri, 21 Nov 2008 00:49:38 +0000 http://wordpress.org/?v=2.6.3 By: steve http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/#comment-1204 steve Fri, 01 Aug 2008 06:26:02 +0000 http://steve.vinoski.net/blog/?p=77#comment-1204 @Rainer: the intent of the article wasn't to explain when to use these approaches, but at the very least, keep in mind that HTTP is basically an application-level request-response protocol while messaging is a lower-level approach that supports asynchronous capabilities such as queueing, fire-and-forget, and publish-subscribe. MQ systems typically have ways to persistently store messages, to selectively receive/filter messages from queues, to send problematic messages to "dead letter" queues, to have multiple applications putting and getting from queues, etc., all helping to create an environment for very low coupling between applications, but with a kind of minimalist approach as far as architecture goes. HTTP, meanwhile, is an application protocol with distinct methods, status codes, intermediation considerations, and state traversal (where the server directs client state via hypermedia), all at the application level. The REST architectural style behind HTTP is pretty specific in its constraints and the system properties those constraints induce, and so RESTful HTTP can be viewed as more architecturally rich and thus more constrained than messaging, but in a good way, given that it obviously can allow and help systems to scale way up. @Rainer: the intent of the article wasn’t to explain when to use these approaches, but at the very least, keep in mind that HTTP is basically an application-level request-response protocol while messaging is a lower-level approach that supports asynchronous capabilities such as queueing, fire-and-forget, and publish-subscribe. MQ systems typically have ways to persistently store messages, to selectively receive/filter messages from queues, to send problematic messages to “dead letter” queues, to have multiple applications putting and getting from queues, etc., all helping to create an environment for very low coupling between applications, but with a kind of minimalist approach as far as architecture goes. HTTP, meanwhile, is an application protocol with distinct methods, status codes, intermediation considerations, and state traversal (where the server directs client state via hypermedia), all at the application level. The REST architectural style behind HTTP is pretty specific in its constraints and the system properties those constraints induce, and so RESTful HTTP can be viewed as more architecturally rich and thus more constrained than messaging, but in a good way, given that it obviously can allow and help systems to scale way up.

]]> By: Rainer http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/#comment-1201 Rainer Thu, 31 Jul 2008 21:04:52 +0000 http://steve.vinoski.net/blog/?p=77#comment-1201 Hi Steve, thanks for the interesting article and the explaining comments on your blog. One thing however is still not clear to me. In which situations is RESTful HTTP the best fit and when are message-queuing systems the preferred solution? Hi Steve,

thanks for the interesting article and the explaining comments on your blog. One thing however is still not clear to me. In which situations is RESTful HTTP the best fit and when are message-queuing systems the preferred solution?

]]> By: Pragmatic Dictator » Mindset http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/#comment-1069 Pragmatic Dictator » Mindset Thu, 10 Jul 2008 21:48:20 +0000 http://steve.vinoski.net/blog/?p=77#comment-1069 [...] developers from making poor implementation decisions which limits the value in re-hashing (Steve, Steve and Stu) RPC rights and [...] [...] developers from making poor implementation decisions which limits the value in re-hashing (Steve, Steve and Stu) RPC rights and [...]

]]> By: Dare Obasanjo aka Carnage4Life - The Revenge of RPC: Google Protocol Buffers and Facebook Thrift http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/#comment-1067 Dare Obasanjo aka Carnage4Life - The Revenge of RPC: Google Protocol Buffers and Facebook Thrift Thu, 10 Jul 2008 14:23:33 +0000 http://steve.vinoski.net/blog/?p=77#comment-1067 [...] interesting. Didn’t Steve Vinoski recently claim that RPC and it's descendants are "fundamentally flawed"? If so, why are Google and Facebook not only using RPC but proud enough of their usage of yet [...] [...] interesting. Didn’t Steve Vinoski recently claim that RPC and it’s descendants are "fundamentally flawed"? If so, why are Google and Facebook not only using RPC but proud enough of their usage of yet [...]

]]> By: anonymous http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/#comment-1065 anonymous Thu, 10 Jul 2008 02:18:19 +0000 http://steve.vinoski.net/blog/?p=77#comment-1065 Fair enough . I guess it was just a rant ... REST tradeoffs are better documented but I don't think they are documented well enough .. and I am afraid that people will first use REST like idiots cos its cool and then suddenly throw it away when they realise its not the dream they had thought it would be. Fair enough . I guess it was just a rant … REST tradeoffs are better documented but I don’t think they are documented well enough .. and I am afraid that people will first use REST like idiots cos its cool and then suddenly throw it away when they realise its not the dream they had thought it would be.

]]>