Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Obscuring HTTP

Ayende has tried to explain why he doesn't like ASP.NET Webforms many times, but based on the comments that pop up on his posts I'm not sure if he's successfully getting his point across. I'll try to help him out in this instance, as I think the same way about not just Webforms, but most other view technologies. This will take more than one post, however, so hopefully I can convince myself to increase my stunning post frequency of the past year in order to properly delve into this issue.

First off, let's take a paragraph or two for a brief refresher on HTTP, the protocol that drives the Web as we know it. This will be quick, and I guarantee it will be dirty...

The HTTP protocol

HTTP is based on a request/response model between a client and a server. The client is assumed to be a web browser in this instance (but can be anything really), and the server is a central location (IP address, domain, URI etc) on the Internet that responds to requests made by the client(s). Responses are generally sent back as HTML documents, but can also be XML, JSON or anything else, really. Each response tells the client what format it is sending via the Content-Type response header. There are many other response headers that provide clues to each client as to what it should do with the body of the response.

When a client makes a request to an endpoint, it specifies a verb that provides a clue to the server as to what the client wants it to do. These verbs are as followed:

  • GET - Means that the client is simply requesting to retrieve whatever information resides at the endpoint URI.
  • POST - Used to send information to the server, which the server can then use to do things like update a domain object. When a POST request is completed by the server, it can send response back in the form of 200 (OK) or 204 (No Content), or more likely a redirect to another URI.
  • PUT - Rarely used and not very well supported, this verb is similar to POST in that the client sends information in the request that it expects the server to act on.
  • DELETE - Also rarely used, this one is pretty self explanatory. The expectation of the client is that the requested resource will be deleted.

The modern web generally just uses the first two verbs (GET and POST) to get things done, although the latest version of Rails fakes out the PUT and DELETE verbs to more closely match the intended spirit of HTTP. One thing that you may notice is that GET, POST, PUT and DELETE look an awful lot like CREATE, READ, UPDATE and DELETE, but that's a "coincidence" for another post.

The way this stuff all gets mashed together to create a usable application on the web is only slightly complicated at the lowest level. In a common use case, a user makes a GET request (through a browser) to a URI that returns an HTML response. The browser then displays the HTML to the user. If the HTML response contains a FORM element, well that's an invitation to the user to change the state of data on the server in some way (maybe by adding a new post to a blog via a few text boxes). When the user clicks the submit button, a POST request is sent to the server that contains all the text the user entered in the HTML textboxes. Once the server receives the request, it's up to the application that drives it to figure out what to do with the data sent by the client.

I hope I haven't lost everyone yet, because I swear there's some sort of profound punchline to be found here.

The Quest For a Simpler Rube Goldberg Machine

Now, I'm sure we can all agree at this point that HTTP is pretty simple. Clients make requests using a verb that may or may not contain data, and the server responds back to the client in whatever way it deems appropriate. The issue that Ayende and I have with Webforms (and Struts, and other view frameworks) is that they take something simple and try to make it different. In the case of Webforms, Microsoft has tried to create an event-driven, stateful paradigm out of something that is resource-driven at it's core.

The result of this is that Webforms has become a layer of indirection that sits on top of HTTP. Indirection in and of itself is not bad; as a guy that uses ORM's to abstract the database will tell you. The problem is that I think it's gone a little further away from the underlying model than it should.

Witness the ASP.NET page lifecycle.

Webforms is an attempt to make web programming look like desktop programming. As a guy who learned about web programming via ASP.NET, I found it was pretty intuitive. The problem came when I ran into leaks in the abstraction that I couldn't deal with without the knowledge of what is really going on under the hood in the HTTP pipeline.

If You Only Read One Paragraph, Read This One

Now the first problem with Webforms is not that it's an abstraction, or even that it's a leaky one (they all are). The problem is that what Webforms attempts to abstract away is actually simpler than the abstraction!

The second "problem" with Webforms is that not very many people know the first problem. I know I didn't, until I saw how Rails, Monorail, and other frameworks are able to work with the underlying model of the Web, while still being terribly simple to understand and develop on top of. Making it easier to program for the Web is a laudable goal, I'm just not so sure that abstracting the technology that it's built on top of to the point where it's unrecognizable is the way to go about doing it.


Posted 06-04-2007 10:09 PM by Jeff Perrin
Filed under:

[Advertisement]

Comments

Mickaël wrote re: Obscuring HTTP
on 06-05-2007 1:25 AM

Very interesting post.

I'm not sure rails "faked out" PUT and DELETE to match HTTP. Roy T. Fielding who is co-founder of Apache HTTP Server Project is promoting REST which is very similar to CRUD when accessing a service exposing database access (Create almost equals to PUT and Update to POST...to simplify).

Rails is definety a framework to expose persistent objects, and then abstraction goes naturaly to this kind of paradigm as soon as you are stateless. Having a state helps a lot and avoid tones of code, you are right, but does not help in a clear layering and separation of concerns. I think that Rails is too heavy for simple staful (aka windows) applications, but enforce structuration of code for larger project.

Next step for all Rails project is to be more dynamic and service oriented...let's see.

Markus Zywitza wrote re: Obscuring HTTP
on 06-05-2007 8:14 AM

Being an active user of MonoRail, I'm quite suspicious to WebForms, but I fear you didn't get the point:

WebForms doesn't abstract the HTTP protocol, which would be doomed from beginning, but abstracts the administrative overhead needed to serve HTTP requests.

This analogous to saying: Why do we need CLR and C# and so on; Assembler is dead simple, why don't we just develop our software in Assembler?

Every programmer with a plain CGI-background knows that she doesn't want to use plain access to HTTP ever again. And you have to keep in mind that even CGI is a layer around HTTP that frees you from writing/parsing headers yourself.

WebForms and MonoRail and other frameworks are just like CGI on a higher level. WebForms is  aimed to have a develop'n'feel like WinForms and therefore has a higher share of complexity than MonoRail or similar frameworks that are more or less service oriented (a request is served by a controller that may render a view or not)

-Markus

Jeff Perrin wrote re: Obscuring HTTP
on 06-05-2007 9:13 AM

Markus,

"Why do we need CLR and C# and so on; Assembler is dead simple, why don't we just develop our software in Assembler?"

I knew someone would bring up this analogy. Again, I do *not* believe the problem is that Webforms wrap up HTTP so that we never have to do CGI style programming again. The issue I have is that learning to program in Webforms is completely and utterly different than the model it is trying to wrap/abstract away.

Jeff Perrin wrote re: Obscuring HTTP
on 06-05-2007 9:49 AM

Mickaël,

The problem is that browsers don't all support the PUT and DELETE methods, so Rails has to do some magic to make it *look* like you're using those to verbs. In the background, I believe they both just use POST.

Scott Bellware wrote re: Obscuring HTTP
on 06-05-2007 11:52 PM

Crap.  Next thing you're going to tell me is that DCOM is no good because it tries to hide the fact that there's a network under that method call.  You're totally harshing my mellow, dude!!  Anyway, gotta run... my head has a date with a pile of sand and I'd hate to be latent for that... :)

Morgan Roderick wrote re: Obscuring HTTP
on 06-06-2007 4:49 AM

Nice post!

I've been very frustrated with the sheer complexity of WebForms for years. It's seems they've added so much complexity, so that lazy VB programmers can build websites, without having to learn anything new. That in itself is scary ...

Getting millions of programmers tied into the WebForms abstraction, is a very good way to stay in business, since all these programmers, will have very little understanding of anything else.

Being of a curious nature, you soon end up being sick of that abstraction tho. ... anyhow, back to work ... doing WebForms :'(

joeydotnet wrote re: Obscuring HTTP
on 06-07-2007 8:26 AM

Very good post.  You've put into words a lot of what I've though for a while now about the unnecessary complexity of web forms.

BTW, just noticed your "about" section...  

"About Jeff Perrin

Jeff is not an internationally (or even locally) known expert in anything related to software development. He holds no certifications worth speaking about, and didn't graduate from University. The value of anything written on his blog should be deemed suspect at the minimum, and blatantly false and misleading in the worst case. Don't let his innate sex appeal fool you... Jeff does not know anything about which he speaks."

Very funny!  :)

Jeff Perrin wrote re: Obscuring HTTP
on 06-07-2007 3:24 PM

Joey,

Yeah, it's a direct reverse-copy of Sam Gentile's "About" section.

joeyDotNet wrote re: Obscuring HTTP
on 06-07-2007 7:37 PM

Ha!  Brilliant.  :P

Ryan Riley wrote re: Obscuring HTTP
on 06-08-2007 10:18 AM

I have only scratched the surface of WebForms, so I can't fully share the pain, but from a theoretic pov, I completely agree with your post. I am interested to see what Microsoft will do with the w3c XForms spec, especially now that they have InfoPath, SharePoint, and the underlying ASP.NET framework driving it all.

I've been playing around with XForms a bit, and while its not the best solution for simple data, it certainly works well for complex forms and applications. Also, given the availability of AJAX frameworks for almost every web programming language, it seems developers, even VB developers, would be better served by going back to plain old ASP and using a JavaScript framework for making their apps appear stateful.

One little quip, though--why are you still hosting your site with .NET if you are so against WebForms? Just curious.

GuyIncognito wrote re: Obscuring HTTP
on 06-08-2007 1:26 PM

Was the ASP.NET WebForm model designed with a GUI designer (VS.NET) in mind?

Is that the reason for the "VB-Like" design?

I personally never understood drag-n-drop for developing web pages and never (EVER) use the designer in VS.NET.

Jeff Perrin wrote re: Obscuring HTTP
on 06-08-2007 3:37 PM

"One little quip, though--why are you still hosting your site with .NET if you are so against WebForms? Just curious."

I'm not. I switched over to Textdrive a few weeks ago. And it's not that I'm against ASP.NET... Just Webforms.

Aaron wrote re: Obscuring HTTP
on 06-15-2007 8:24 AM

WebForms are bad for other reasons.  I moved from working with a combination of Smarty/PHP in college to .Net WebForms in the business world.  The sheer overcomplexity to design a simple site astounded me (with the exception of the DataGrid, which is probably the most worthwhile .Net control).  Your mode of thinking has to change -- instead of having access to the underlying HTML and manipulating it directly, everything becomes an wrapper around an abstraction.

I always thought that in using VB.NET and ASP.NET to develop web pages, most amateur programmers become addicted to the drag-and-drop, which eventually causes their apps to fail because there is too much going on behind the scenes that they do not understand (or do not want too).  If they are successful in building an application of even moderate complexity, then it becomes  an unmaintainable,  cryptic, monolithic mass.

Meanwhile, I think it would be easier to teach them (and for them to grasp) basic PHP, HTML, and Smarty Template design (or any other basic scripting language).  Overcomplexity and reliance on an IDE feeds ignorance  and waste -- most VB (again in my experience) programmers do not know the difference between private and public variables anyway, not to mention OOP techniques, or anything to do with the HTTP protocol.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)