Demand Driven Architecture or REST or Linked Data?

I recently listened to David Nolen‘s talk from QCon London conference from back in July called Demand Driven Architecture. Before continuing, you should have a listen.

Ready?

I really like a lot of things Mr. Nolen has done and really enjoy most of his talks and posts. I was less enthused with this one. I think my main hang up was his mis-representation of REST and resources. I get the feeling he equates resources with data stores. If you watched the video and then skimmed that Wikipedia page, you will quickly see that the notion of “joining” two resources is nonsensical. I think Mr. Nolen is really referring to that “pragmatic” definition that means POX + HTTP methods, which really would correlate well to data stores.

Real REST drives application state, so you would not need to join to anything else if using REST. His criticism of performance also misses the mark, for if you are using REST then you should also be carefully planning out and leveraging a caching strategy. REST isn’t appropriate for every application, but not for the reasons Mr. Nolen so casually dismisses it. Think about it this way: if REST is not suitable for performance or mobile devices, then you must also agree that all websites (not apps, just sites like Amazon.com) fail on mobile devices. That’s just absurd.

I can’t imagine anyone is surprised when Mr. Nolen mentions SQL. He’s just mentioned joins, and what else would a developer associate with that term? If you have hung around the web long enough, you may have heard of SPARQL, which is a query language for linked data. Linked Data and SPARQL never seem to have caught on, but they address at least part of the problem Mr. Nolen presents. A big part of Linked Data’s failing is lack of tooling and painful implementation (mostly related to RDF). Perhaps new tools like BrightstarDB will help turn things around.

Interestingly, Mr. Nolen’s solution, SQL, is strong at ad hoc querying but not so great at scalability. If the web, linked data, etc. were already addressed by SQL, then those technologies would not exist. I really don’t get the need for mis-representation and indirection here. (On a related note, Fabian Pascal recently posted on the “Conflation & Logical-Physical Confusion” surrounding mis-representing SQL as the relational model, which ties in well to this post.)

The only thing presented here is an alternative to REST where the client specifies dependencies for the server to fulfill. This is a flip of the REST style where the server drives application state and provides contracts via media types to a client-driven approach. This is a perfectly valid approach, and interestingly one where Linked Data could excel. Tools such as Datomic, GraphQL + Relay, and Falcor certainly look interesting and appear to work well for very large projects.

I have no doubt that any of these techniques, done well, provides excellent results. Tooling will likely determine the winner, for better or worse.

The Origin of RESTful URLs

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!

New Names for Old Things

[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.

Web Architecture Done Right

I’ll go ahead and confess that a single right way to design for the web doesn’t exist. If someone wants you to believe otherwise, they are just wrong. That said, I do think that you’ll have a hard time going wrong by starting with one simple rule: start with a web api.

Why should you start with a web api rather than just building a web site/app that has HTML and JavaScript all working together? Frankly it’s because you can’t properly decouple the api from the serialization format well enough. When you are designing an api for the web, you (should be) thinking in terms of resources and representations. That’s representations in the plural form. You may not know exactly what forms you’ll need, but you should consider that you will eventually have many. When you start with a web site/app with HTML in mind, you’ve coupled yourself to a single format, and extracting that out later could (will) be difficult. Don’t just take my word for it. Mike Amundsen has an excellent post on the right way to think about these things.

There are certainly some instances where this may be overkill, but I hate rewriting software unless it really is a prototype or just an exploratory attempt to get something up. In those cases, go for the quick and dirty. If you are working on something you want to last a long time, however, you owe it to yourself to consider the evolvability of your app by focusing on api design. You’ll then be able to take advantage of a number of client options. Certainly, supporting the growing number of clients is one of the biggest challenges continuing to face developers as we head into 2012.

Let’s suppose you agree with me on this point. How do you go about building a really solid api design? I don’t think I could articulate it better than Darrel Miller already has. His goals for good apis are suitable both for internal teams and external customers. Who wouldn’t love gaining visibility b/c a customer was able to accelerate their business by using your api in an unforeseen way that drives additional business for your own company? How nice is it to knock out not just one project but several b/c you are able to leverage existing platforms for new projects? We’re doing that at Logos, in large part because we moved to MVC and took a more service-oriented approach to building our apps. The number of new projects has grown tremendously, but we are also able to respond much more quickly b/c the services are ready for consumption.

I’ll be continuing to discuss this topic in future posts. In the meantime, check out Mike’s book,
Building Hypermedia APIs with HTML5 and Node. It uses HTML5 and Node to illustrate, but the concepts are excellent and portable to other platforms. I also highly recommend REST in Practice as an excellent resource for understanding the fullness of what HTTP offers for building apis. Enjoy!

Re: unREST

Tried commenting on the unREST blog post, but I kept getting an error that I was trying to post illegal content.

  1. You equate the HTTP version of REST with REST itself. That is inaccurate. I think what you don’t like is HTTP.

  2. I’ve never understood why SOAP didn’t drive directly off of TCP. It doesn’t really use HTTP except for transport, which is really useless.

  3. I’m all for different application protocols. Build your own indeed. You are quite right that, in many cases, another person’s uniform interface is not the best. These can be REST or not, that’s really up to you.

  4. I find REST breathtakingly simple. I like it, so I apparently disagree with you, and I’m alright with that.