Catapult Systems, my employer, is hosting several of the upcoming Windows Azure Dev Camps. I’ll be helping out with two in Denver (April 25) and Houston (April 29). The Dev Camps will provide you with an overview of Windows Azure and an opportunity to complete several Hands-on Labs, including topics such as IaaS and Azure Mobile Services.

If you plan to attend one of these events, or if you are just curious to see what Azure can offer, sign up for a free 90-day Azure trial. If you are a student, you should also sign up for Dreamspark, which includes a free Windows Store developer license. (You need the Windows Store developer license to send push notifications to a Windows 8 client.)

Sponsors

Pluralsight was kind enough to provide an Annual subscription to their online developer training library of over 450 video courses, a $299 value, as a raffle prize.

Telerik also provided a DevCraft Complete license for the raffle!

Please note that you must be present to receive one of the above prizes during the raffle at the end of the camp.

In .NET Rocks episode 855, Jeff Fritz commented on ASP.NET Web API being somewhat confusing in terms of its intended use. I don’t tend to agree, but I thought I would address one point he made in particular: that Web API is perhaps just another form of repository.

Web API is much more than a repository. And yes, it is indeed a protocol mapping layer. As Uncle Bob once noted, a web or api front end is just a mapping layer and is not really your application.

In many cases, however, one could argue that a web-api-as-repository is a fairly solid use case. OData is a great example. However, I was thinking of yet another argument I’ve heard for dynamic languages: when you are just going from web to database and back, you are not really working with types.

In that spirit, I set out to write a simple Web API using SQL and JSON with no explicit class definitions. You can see the results in this gist:

I used Dapper to simplify the data access, though I just as well could have used Massive, PetaPoco, or Simple.Data. Mostly I wanted to use SQL, so I went with Dapper.

I also model bind to a JObject, which I immediately cast to dynamic. I use an anonymous object to supply the values for the parameters in the SQL statements, casting the fields from the dynamic object to satisfy Dapper.

All in all, I kinda like this. Everything is tiny, and I can work directly with SQL, which doesn’t bother me one bit. I have a single class to manage my data access and API translation, but the ultimate goal of each method is still small: retrieve data and present it over HTTP. That violates SRP, but I don’t mind in this case. The code above is not very testable, but with an API like this I’d be more inclined to do top level testing anyway. It’s just not deep enough to require a lot of very specific, low-level testing, IMHO.

Also, note again that this is just retrieving data and pushing it up through an API. This is not rocket science. An F# type provider over SQL would give a good enough sanity check. Why bother generating a bunch of types?

Which brings up another point for another post: what would I do if I needed to add some logic to process or transform the data I retrieved?

As a future exercise, I want to see what it would take to cap this with the Web API OData extensions. That could be fun.

I recently ran into a problem with accessing a WCF web service over https. I used the WSDL Type Provider to generate the service client for me. I referenced System and System.ServiceModel like a good boy, yet I couldn’t find any way to set the credentials for the service. I began by trying to use the generated client: MyService.GetWSHttpBinding_IDataService. Unfortunately, that didn’t have a the ClientCredentials property I expected. So I then tried creating a new client:

1
2
3
4
5

let endpoint = "WSHttpBinding_Test"
let username = ""
let password = ""
let client = new MyService.DataServiceClient(endpoint)
client.ClientCredentials.Windows.ClientCredential <- new NetworkCredential(username, password)

Unfortunately, the issue persisted. I then noticed a little message noting that I was missing an assembly reference. Turns out you must also open System.IdentityModel. Problem solved.

NOTE: If anyone knows of an https hosted WCF service in the wild, I’d be happy to share the full code.

I would like to propose an alternative compilation structure for building F# projects. I’m currently calling it an F# manifest, though the actual idea is less focused on the creation of a single file and rather on a different, language-first approach to building projects. My idea stems from a technique I’ve started using more regularly and that I’ve seen from Tomas Petricek. This technique uses compiler directives for toggling #r and #load commands for F# Interactive. Using these, you can typically run a script or compile and run an executable. The overall process would roughly appear as follows:

1. Look for a Main.fs or Manifest.fsx file.
2. If a Manifest.fsx file doesn’t exist, generate the Manifest.fsx from #if INTERACTIVE, #r and #load references
3. Do this for all referenced files so that the Manifest.fsx lists the dependencies for the primary script
4. Search for references without a path in the local directory, then the GAC, and finally NuGet

Why an alternate build system?

Today I saw a question about docs for F#x on the F#x mailing list. The first reply, from Art, referenced Tomas’ FSharp.Formatting project. I hadn’t seen Tomas’ project in some time, so I went to check it out. The last I looked at it, FSharp.Formatting provided a Markdown parser. Tomas has extended it to cover a much larger feature set, including a version of literate programming. Literate programming was the ultimate goal of my halted focco project. As I had always intended of pulling in several of Tomas’ other projects to finish focco, and FSharp.Formatting now provides many of those features, I will now be moving what I can from focco over to FSharp.Formatting.

That was what I had originally planned to write about. Instead, worn out from the holidays, I lost focus and instead started thinking too much about true literate programming. (Disclaimer: I have not investigated Tomas’ implementation in any detail, so some of what follows may be inaccurate.) Knuth’s idea of “literate” programming allow programmers to write for people and use a tool to strip out the code and re-organize it for the computer. This sort of thing is more necessary in languages such as F# and Pascal you must first declare a procedure or function before you can use it. Neither focco nor FSharp.Formatting currently addresses this.

Before literate programming in F# is really possible, we need a build system that can work more directly from raw files. Well, that’s not entirely true, but I’ve long wished to see less XML and more F# in my F# builds.

Is this really a necessity to literate programming in F#?

No, of course not. I just found myself thinking through all this and thought I would write it down for posterity. If I really thought it necessary, I would have instead started writing some code to feel this out. Instead, I’m planning to get some sleep and try to focus and get F# project support added to FSharp.Formatting. Once that is done, we’ll see about allowing a mechanism to allow authors to list their code in an arbitrary manner and then reassemble it. And after that, maybe a look at a new build system is in order.

And no, I haven’t forgotten about FAKE. If nothing else, I would probably make this an optional extension via FAKE. Then again, you can already do some of this with a single .fsx script several loose .fs files, and some assemblies.

I just happened to drop over to the ASP.NET Web Stack and noticed that nested controllers are now allowed in Web API! This is terrific news for you F# developers who, like me, think that grouping related functionality, including controllers, within modules is a convenient practice. Note, that this is only in the source. You won’t be able to update your NuGet packages to get this functionality, though it is easy to replace the offending DefaultHttpControllerTypeResolver with this updated copy:

1

config.Services.Replace(typeof(IHttpControllerTypeResolver), new MyHttpControllerTypeResolver())

For at least the past year, I have repeatedly found my appreciation for the literal offended by the term “RESTful URLs.” I recently spent a bit of time trying to explain how this term is oxymoronic on the Web API Forums. While URIs are important as a means of identifying unique resources, REST doesn’t specify any other requirements for URIs. I often note that a RESTful URI could be a GUID. While this is certainly not very meaningful to humans, it satisfies the REST constraints.

While pondering nested resources in Web API yet again, I realized where I think this term originates. Ruby on Rails used the term “RESTful routing” to describe their approach to building Controllers along the line of resources and using a convention to route controllers in a hierarchy based on the controller name. The goal, I think, was to correctly model and mount resources at unique URIs. However, you get what I would call “pretty URLs” for free.

If you use the term “RESTful URLs,” please stop. While RESTful Routing makes sense, RESTful URLs are just nonsense. Do use “RESTful Routing.” Do use “Pretty URLs.” Just don’t confuse your terms. Thanks!

I finally published the first in a series of short, video tutorials describing web programming in the functional paradigm. The first video briefly introduces the tools I’ll be using: F# and ASP.NET Web API.

Here’s part 1:

I’ve been using a big of knockout.js of late, and while I don’t mind the ko namespace stuff, I do wish that this had used RxJS instead. I know Steve tried that early on and all; it would just be nice to be able to leverage something with which I’m more familiar. Perhaps Matt Podwysocki or Christopher Bennage will come up with something.

[This is the third in a series started long ago on the use of MVC for building web “applications”.]

I’m glad I’m only getting back to this series now. I’ve had an opportunity to build many more web applications and have a much better appreciation for the poor terminology used to define web applications. For starters, this MV? business silly. We’ll get to that.

I know I’m a bit of an extremist in some things. Specifically, I like things to mean what they mean. When we abuse terms, we don’t communicate well. REST. There, I said it. I feel better. Stop using the term. Most people have a wrong idea of what it means b/c of all the silliness that has been done in its name. I don’t claim to know exactly myself. I don’t think it’s possible to rescue the term from the abuses heaped upon it. There, you see? I’m an extremist.

Now that we’ve covered that, on to MVC. I’m not sure who decided this was an accurate description for what happens on the server-side of the web, but it’s just flat wrong. As noted previously, HTTP uses a functional interface. It’s an IO-bound Request -> Response function. Can you use patterns on either side to help maintainability? Certainly! Just don’t confuse things. Let’s start with Views.

Views

What is a view?

The [view or viewport] is responsible for mapping graphics onto a device.
A viewport typically has a one to one correspondence with a display surface
and knows how to render to it. A viewport attaches to a model and renders
its contents to the display surface. In addition, when the model changes,
the viewport automatically redraws the affected part of the image to reflect
those changes. […] there can be multiple viewports onto the same model and
each of these viewports can render the contents of the model to a different
display surface.

If a view was merely a serialization of a model, this would make sense for building web applications. Unfortunately, there’s a problem. The definition suggests that the view automatically updates whenever the model changes. How do you do that with HTTP? HTTP doesn’t define any mechanism for hooking up observation of a server model. Before you say JavaScript, consider first the current use of View, or even UI. People commonly mean HTML. HTML is not a UI. HTML is a serialization format. The client (normally a browser) must interpret that HTML. Many of you will remember when that wasn’t so standard.

Can we achieve MVC today? Possibly. You might be able to leverage web sockets to reach across a client/server architecture such as that presented by HTTP. However, you are more likely to find that “MVC” on the server is just limiting. You are typically better off building a sort of restricted data access service, a.k.a Web API (subtle hint). There’s really no point in trying to enrich a serialization format to make it work more like true MVC across the client and server.

Controllers

This is no different than routing. Instead of calling your Router a Controller, you split them up. However, most frameworks really just use the router as a top level dispatcher and the controller as a lower-level dispatcher. Otherwise, I’d say web frameworks stay a lot closer to the original meaning than a lot of the other MV? patterns. (Hence the ?, of course.)

Models

This really is the crux. HTML is a model. I noted this last time. It’s just a serialization of data you want displayed. It happens to be a lot richer, but it’s still just a data model. HTML is a great way to bootstrap an application that otherwise uses JavaScript as a model serialization format. If you want to disagree, ask why HTML5 removes the presentation elements. Why has layout and style moved to CSS? CSS and the browser define the actual rendering. In a no-script web application, you don’t have to build a view. You get it for free.

Conclusion

So what? Am I just ranting that I don’t like how people abuse terms? Possibly. However, I think this goes deeper. When you allow the slippery slope, you get caught on it, as well. It’s inevitable. The bigger, lurking danger is that we start to confuse useful patterns and use them in the wrong places. Many people use MVC frameworks today to build web APIs. However, that’s not MVC. So if you then switch to a desktop app to write MVC applications, you are either confused or delighted to find that it’s so much richer.

I don’t know what I would call what we build for the web; I know I wouldn’t call it MVC. In my experiments with Frank, I’ve found that writing simple functions and nesting them with rules makes a very easy mechanism for building web APIs. I think that would essentially just be a Command pattern. Simple, elegant, and very easy to understand. YMMV.

If you have been trying out ASP.NET Web API, you will be happy to know that the RC is finally available. No more struggling with building the sources yourself or fumbling with installing the nightlies to the GAC. Henrik has posted a few articles on the changes, as well as a follow up to using the nightlies with the RC release, if you must. One final note: the assembly names have changed, I assume to allow you to install the MVC4 for VS2010 alongside a VS11 installation, which was previously not possible.