Hacker News Reader

Comment by MehdiEG | Hacker News Reader

I have to say that I was equally puzzled by this post the first time I read it. Perhaps having some background information about what exactly he's working on might have helped.

On a second read, it looks like the meat of the post is about decoupling the implementation of your API from the underlying network protocol. Unless I'm missing something, that would be MVC.

Controllers are completely oblivious to the fact that HTTP is being used behind the scene. The routing mechanism takes care of parsing the request, deserializing the request body, instantiating the appropriate controller and invoking the correct action passing the deserialized objects as parameters. Once the controller's action has completed and returned its result, the View is responsible for serialising the response to HTML, JSON, XML or whatever serialisation format you use, and for setting the correct HTTP status code and headers.

So still puzzled, even after a second read.

View on HN

Trying to over-abstract network communication is one of the classic mistakes in distributed system design.

Remember the old "RPC" idea from the 1980's? Despite a huge amount of effort to optimize remote procedure calls, nobody could ever get an RPC to be within orders of magnitude of a real procedure call in speed.

The RPC concept only became mainstream in the 2000's when people had given up on performance; SOAP and POX systems use inefficient XML and JSON serializations and are integrated into http stacks that were designed to use something else. These systems flourished in the 2000's because interoperability, not performance, was the driver.

Now, if you're in an AJAX, Flex or Silverlight environment, you've got the whole asynchronous communications issue -- you can't paper that over with an abstraction layer, you've got to build the whole application around the fact of async comm if you want to build something that really works.

Abstraction gone wrong almost always come down to wanting to abstract for the wrong reasons. RPC was all about pretending from the client side that accessing a remote resource was the same as calling a local method. This was and still is non-sense and a prime example of leaky abstraction.

My understanding of the OP's post is that he is talking about server-side issues rather than client-side though. Others have pointed out that he's talking about the design of a specific python library or framework that I'm not familiar with - I'll need to read up on this first.

We're not abstracting HTTP away, we're just looking at the whole thing differently. In a way our code is RESTful and considers HTTP a way to implement REST. XMLRPC and other things throw all of HTTP over board with the exception of the entity body which removes all the advantages and reasons to use HTTP.

Our stuff gives us an unified API and it's fully embracing HTTP.

Reply on news.ycombinator.com