OpenRasta status update

This entry may be outdated. For the latest updates on openrasta, see www.openrasta.com.

A couple of people have access to the code and have been kind enough to give reviews. I’m always open to more people helping out in the very early design phase before I go all public with the framework I’ve been nagging everybody about for months and months, so pop me an email to seb@serialseb.com and I’ll give you access. OpenRasta will be under an MIT license and I’ll publish it all to the world. I need to ensure what needs refactoring before release is refactored and that it is a fully functional beta first.

So here is what can be done with OpenRasta now and what I’m currently working on. See it as both an announcement and my task-list to the runner-up to the official release. You can refer back to the previous version of OpenRasta I already introduced. For various reasons the original Rasta never made it to open-source and its code has now died, and as far as I know no one will maintain it. OpenRasta is a fresh take on it, but keeps the same configuration API and the same concepts in a fresh new format with fresh new codes (and fresh juicy unit tests).

So by now you know there are essential components in OpenRasta: URIs, Resources, Handlers, Codecs and the pipeline.

The framework

  • OpenRasta.dll contains the bulk of the implementation, and compiles successfully on the .net framework 2.0 and on Silverlight. Great for embedding OpenRasta in your traditional asp.net application and start migrating your code over. And why not provide a REST-friendly server from the .net Compact Framework? (starting to sound like a marketing drone there)
  • The silverlight support will eventually provide for duplex http so you can architect your RAI test-first and REST-friendly, reduce coupling, and enjoy your life more. IN PROGRESS.
  • Most of the features are implemented straight into OpenRasta, such as dealing with form content-types browser send you. That means no reliance on some of the asp.net limitations on file uploads.
  • OpenRasta.Server.dll is your asp.net integration point, with support for traditional IIS6 and Integrated IIS7 modes.
  • Did I mention OpenRasta runs on asp.net 2.0? Alongside your webforms?

The pipeline

  • The pipeline is a series of pipeline contributors. They all act upon a small area of functionality, change a couple of things and give control back. The good news is that you have full power to change any of the existing contributors, add your own, etc. The default pipeline has 17 components which support the execution of the whole system.
  • Each contributor registers when it wants to be executed, and it is always relative to another contributor. The pipeline, once initialized, builds a chain of calls and execute them sequentially. And there is a small type that will let you register for multiple steps in the pipeline and be called only when you are ready.
  • You can add and remove contributors at configuration time to replace or modify existing behavior. IN PROGRESS.

URIs and URI decorators

  • You define your resource Uris using the common http template syntax. It’s a clean-room implementation of the .net 3.0 UriTemplate and UriTemplateTable classes to run on 2.0. It will support both the 3.5 modifications and some extra features sometime in the future. May donate the code to mono if their implementation hasn’t progressed much.
  • Several Uris can identify the same resource, but in different languages. /home and /accueil will automatically set-up everything you need to override the default client’s language.
  • Of course, in any real-world scenarios, your URI doesn’t only describe an abstract resource that is easy to name. There are plenty of little tidbits of things you may want to include, such as the document type (.html anyone?), the language (/en/mydocument), maybe even the version (/en/mydocument(v1)). Most frameworks would have you declare all the combinations of those urls to design your resources. In OpenRasta you simply define a Uri decorator that will change the way the request is processed and clean-up the Uri before passing it on for processing. Out of the box, you’ll have document types, language, http method overrides (for those nasty PUT you want to do from your html forms) and view selection (for when one resource have several views applied to it).

Handlers

  • Once your Uri is matched to a resource, a handler is going to be selected and one of its methods called.
  • You don’t have to inherit from anything, or implement any interface.
  • You name your method using the name of the http method the client sent you. Want to send data? Implement a Get(). Want to append data? Implement a Post().
  • Sometimes you want more meaningful names. Just declare a small attribute to map the correct http method to the correct clr method.
  • Parameters are declared naturally, without multitudes of hacks, strings or attributes. The codec will be responsible for mapping whatever the client sent to whatever CLR types you are expecting. The framework will map your url templates to your parameters too.
  • Want optional parameters? Add an [Optional] attribute. Want a default value? Enter [DefaultValue]. And any CLR language implementing default values will support those too. I think that includes the VB guys :)
  • You can even have parameters that map to http headers.
  • Your handler method returns what makes sense to you. Don’t want to return any resource to your client? Discover the joy of the void return type! Always return a type? Just declare that type as the return type. And when you want to return RESTful information, simply return an OperationResult.
  • Your handler only select objects, not views or other things that doesn’t concern it. You return an object and a Codec will render it to the client.
  • And of course, you can add plenty of filters that execute before and after the method calls. A logging filter (IN PROGRESS) and a Principal security filter come out of the box, so you can get people to authenticate.

Codecs

  • A resource can be read and written from and to an http connection using Codecs. Some are provided in Rasta (json, xml, html, html form data), and writing one is brain-dead easy.
  • You can let the client decide which content-type it will receive by using well-established content-type negotiation semantics. It’s all done for you. And it even serves application/xhtml+xml to firefox without you having to touch a line of code.
  • When sending data from html forms, <input name=”customerName” value=”value” /> will call Post(string customerName);
  • Ok, everybody does that. When using <input name=”Customer.Name” value=”value” /> this will call Post(Customer customer) with the correct property done for you.
  • Ok, most MVC frameworks do that. When using <input name=”AddressOf(Customer).PostCode” value=”value” /> this will call Post(AddressOf<Customer> customer) with the postcode property set.
  • Ok, some MVC frameworks do that. When using immutable types, <input name=”Customer.DateOfBirth.Date” value=”12” /> the method Post(Customer c) will be called with the date set on a new date of birth. And you can set property chains as far as you want, and write to read-only properties. Convinced yet?
  • Ok, maybe some MVC frameworks may be able to do that. When using <input name=”Customer.DateOfBirth.Date” value=”12” /> the method Post(ChangeSet<Customer> c); will be called, and you can update your objects with whatever changes are being sent through.
  • Oh, and the same stuff can work with other content-types too. Implementing http patch has never been that easy.
  • Codecs also can use different views. Want to have one page to view and one page to edit your customers? Just declare a view using TranscodedBy<WebFormsCodec>(new { index = “~/CustomerView.aspx”, edit = “~/CustomerEdit.aspx” });
  • The return data depends on what the client requested. And that includes error pages, 404s, 401s, etc. IN PROGRESS.
  • You can stream data from the client rather than have asp.net download everything for you, for any multipart type. IN PROGRESS.

And the rest

  • Http Digest Authentication out of the box. IMPLEMENTED. With time-sliding security window and logoff functionality! IN PROGRESS
  • An error mechanism for your webforms to manage validation errors while still returning RESTful status codes, that still renders correctly when dealing with json, xml, etc. IN PROGRESS.
  • Everything, and I do mean everything, goes through an IoC container. If you don’t use one, OpenRasta use its internal one. If you use one, OpenRasta automatically registers all its dependencies in it. Comes with a Windsor Castle implementation.
  • All the configuration can be done without a single attribute anywhere, either by leveraging conventions or using the fluent configuration API.
  • Automatic cache management based on your resources (including Last-Modified and ETags). IN PROGRESS.

What to look forward to in beta 2

  • VB9 XML literals, NHAML and NVelocity view engines. NOT STARTED.
  • Full AtomPub support. NOT STARTED.
  • StructureMap support. NOT STARTED.
  • An additional configuration mode for the attribute junkies that will scan your assemblies and configure OpenRasta automatically. NOT STARTED.
  • Support for asynchronous operations (need to define the exact use-cases for this first). NOT STARTED.
  • An optional reverse cache for your handlers. NOT STARTED.

Way past my bed-time. That should give you a good idea of where I am at with OpenRasta and what kind of things it will enable you to do. Email me to peek at the code before anyone else!

Ads

Comment