mca blog

one thing i've internalized over the last year is that Fielding's REST model outlines a set of constraints that lead to scalable network applications. it's that word that is, IMO, the key to success - constraints.

to test this theory, i've spent the last year working on a Web programming library (in C#) that is designed around the notion of "Constrained Web Programming." my thinking has been that the key to successfully building and implementing highly scalable Web apps was to 'force' developers into adhering to the key constraints (as i interpret them) outlined by Fielding in 2001:

• Constrain addressing of server resources via standardized URIs
• Constrain resource representations via standardized MIME-types
• Constrain communications between user-agents and servers via standardized HTTP Methods
• Constrain message meta data via standardized HTTP Headers
• Constrain user-agent and server message-handling via strict support for intermediaries

to this end, the exyus library provides a 'layer of constraints' with which a developer can implement a Web application. the following are 'first class' elements of the library:

• Resource classes are built on a base class with a constrained set of public methods (Get(), Head(), Options(), Post(), Put(), Delete()).
• Resource classes are 'published' through a collection of URI patterns applied directly to the class.
• The public methods of Resource classes must contain one or more MIME-Types that are automatically checked against the published capabilities of the user-agent.
• authentication and authorization is implemented via standard HTTP Auth + URI; no 'hidden data' is used to secure resources.
• Developers can tweak the automatic validation and expiration caching built into the library in order to optimize support for intermediaries.

while the library is not 'fully baked,' i can say from recent experience that working with a constrained model from the start has clear advantages when it comes to building highly-scalable applications. first, it turns out it is actually difficult to build state-ful apps w/ this library. second, since the library is so focused on standardized methods and resources, it becomes second nature to start modeling your problem using these concepts (rather than converting an existing model into state-less resources). third, since authentication and authorization are constrained to URIs and HTTP authentication headers, it forces developers into making sure any resources that require security are sufficiently defined at the URI level. fourth, since MIME-types are a first-class item in the library (and are abstract from the actual resource), it allows developers to focus on the proper MIME-type for the situation and it is much easier to build applications that support multiple MIME-types for the same resource when that is desired. finally, since caching optimizations are automatic (and somewhat cumbersome to undo), building scalable Web apps is easier and breaking caching becomes a bit harder.

in the last several months, i've found myself spending more time modeling resources, more time determining the proper MIME-types to support, less time coding low-level request/response and auth-n/z code and less time dealing with session and other state-ful items that hurt security, scalability and performance. in the end, i'm writing less complied code, getting more work done, and enjoying the process more than i can recall.

i encourage folks to check out the library. it's all open source and available for use. i still have work to do to improve usability and testability. i plan to continue to tweak and update the code over the next few months and i look forward to feedback from anyone using (or attempting to use) the library.