barcampRDU 2007

camping
© Patrick Mueller

On Saturday I attended BarCampRDU 2007, and here's a quick round-up.

First, thanks to the organizers and sponsors; it was fun geeky way to spend a Saturday, and the amenities were fantastic, especially considering the price of admission. Especially enjoyed the catered coffee bar and lunch from Neomonde.

Here's a list of some of the sessions that were run:

Juggling Distributed SCM - Bazaar, GIT, etc Camping in 10 (Ruby) Linux virtualization Bug House, a chess variant Podcasting Ruby and X-10 TDD Extending SketchUp with Ruby GTD

OpenMoko Grails Geeks for Good Startup Weekend What's stopping you from doing something? Open Services OLPC Digital Identity Management FaceBook application development

Lots o' pictures here, and lots o' blog entries here.

Some of the sessions I went to:

Camping at 10
Very cool; I really need to dive deeper into Ruby. Completely random factoid: of the 15 laptops in the room for this session, 12 were Macs.

FaceBook application development
Quite illuminating. I had thought all those 'user generated' FaceBook apps were actually hosted by/on FaceBook, but they aren't. Which makes me even more leery of what those applications are doing with the data we're giving them. hmmm

Open Services
Whereas Open Source / Free Software has defined freedoms surrounding source code, the next battleground on the freedom front are the services we use on the web. What does it mean for something to be an "Open Service"? Not sure why Luis thought he "trivialized the discussion"; absolutely not. Lots of really interesting things to think about here. Especially as we find our data getting mashed up and otherwise reused in ways we never expected.

Other notes ...

Rather than take my laptop into the unconference, I decided to try living with just my Nintendo DS-Lite with the Opera browser. I've surfed a bit here and there with it, but not for an entire day. While it's quite capable at handling degraded 'mobile' sites, available for Google Reader, GMail, and Twitter, for instance, it's rather painful for websites designed for desktops. Most folks probably won't tolerate the slow, small device, especially compared to the iPhone. But having worked on embedded devices for years, I can easily overlook the limitations. It's a lot cheaper than the iPhone also.

All in all, worked out pretty good; checked my mail, checked twitter, checked blogs; posted a few twitters. A bit painful, pecking out messages on a tiny touch screen with a stylus, but worth it to not have to lug my MacBook around in a backpack. Just had to lug around my man purse.

Lastly, one thing I already knew, but had reinforced, was that all the kewl kids wear bright yellow / orange shirts from Threadless.

how RESTy need we be

That's Good Enough for Somebody
© Edward O'Connor

A few blog posts reverberating in my mind:

I just ran across a post by Joe Gregorio today, where he's comparing WS-* RPC vs. REST, specifically talking about the fact that WS-* RPC only uses the POST request method of HTTP:

"That POST of a generic media type gives no indication if the request is safe, or idempotent, nor is there any indication of the cachability of the response."

I also just read this morning a post by Leonard Richardson on Amazon's new FPS service, commenting on the 'REST'y ness of the service:

"its 'REST' interface is about as RESTful as Flickr's and del.icio.us's 'REST' interfaces"

Note, the Flickr and del.icio.us aren't considered terribly RESTy. :-)

Joe notes a handful of things that "just using POST in HTTP" breaks. Leonard notes that FPS isn't truly RESTy, but is in fact just as non-RESTy as two other fairly popular services.

And I'm left wondering: do we really need to do everything in pure REST?

Perhaps we can identify a small set of characteristics that get us most of the benefits of REST, that would be easier to implement than going 'full' REST. And just focus on those. Because apparently, it's hard to do full REST. Or to be even more pessimistic, perhaps there are disadvantages to using REST. Why would Amazon and Yahoo not use REST?

Most of the obvious advantages with REST revolve around the GET verb. Make sure you only put safe, idempotent actions behind the logic of your GET processing. Use ETags, or even better, cache directives, in your HTTP responses on the GETs to allow clients to intelligently cache things.

What else? Are there really other benefits? If there are, why are people still not jumping on the RESTy bandwagon?

Here's my thought on the lack of adoption of REST: it's complicated for anything but the GETs. Namely, the mutating verbs POST, PUT, and DELETE. Not technically, but semantically. Check the rest-discuss mailing list sometime. I've been having conversations with folks here recently regarding some of the semantics of 'updates' as well; ask 5 people their thoughts, you'll get 10 different answers.

Martin Nally had told me a few months ago that he thought people should be able to do 90-95% of their services in a RESTy style, and for those interfaces that didn't fit the REST mold, you could do 'em in non-RESTy style (ie, some kind of RPC-ish non-GET mutation operation), but it should cost you a $1000. I think I'm ready to lower the price to $100.

---

Updated on 2007/08/03 to fix a syntax error in the image element.

client generation

Handmade burgers
© Becca G

Dan Jemiolo: What kind of client generation are you looking for?

~shiver~

I suppose I must not have gotten around to telling Dan my horror stories of using WSDL in the early, early days of Jazz. The low point was when it once took me two working days to get the code working again, after we made some slight changes to the WSDL. Of course, we were doing some evil, evil things, like parsing Java code with a JDT jar in an ant task, and replacing generated code from the WSDL generation process. But still, code generation of this ilk leaves a bad taste in my mouth.

Also see Dare's issues with bananas.

The best code generation is no code generation.

And that's what we changed in Jazz. Because we already had complete control over the data typing story (EMF), we had no problem generating the XML and JSON we wanted, completely dynamically, by reflecting over the data used in our services. But we had to do something about the service methods themselves.

So we rolled our own client and server side stack for this.

We kept the notion of defining the operations in a web service in a Java interface, because this makes a lot of sense to do in Java. We can reflect over it to look at the methods and signatures. On the server, you can write a class to implement the interface, and that's your service implementation. The low-level server interface (ie, Servlet for Java) can figure out what service to invoke, and then call the service implementation reflectively. And on the client, you can use Proxy and friends to build an object which implements the interface by making the HTTP request on your behalf.

(Quick aside to note that Jazz services are largely RPC styled, though there are some that are more RESTy flavored - stay tuned; they've caught the REST bug. I think the 'client library' or invocation style is largely independent of the architectural style, so I think everything I'm saying here completely holds for REST as well as RPC, and everything in between.)

By having the client and server work completely reflectively, all we had to do was make sure the data classes and service interfaces were the same (or at least compatible) between the client and server. Understand, "all we had to do" can be a problem; but at least we didn't have the generated code to deal with as well, nor did we have a separate build step for it that can be an agility killer.

It goes without saying that you can get by with a lot less configuration in such a situation. Reflection over Configuration. Don't Repeat Yourself.

Looking back on this, I think this was a great trade-off in the time expended to build the stacks. For instance, we were able to tweak the system in various ways that would have been impossible to do with a code-gen built system. I suspect this is going to be the case for any medium- to large-scaled system built using a number of services. You can either lock yourself into a system under which you have very limited control, and spend your time working around it and fighting it, or you can write code customized to your needs and spend time tweaking as you need.

Let's get back to your original question, but tweak it a bit: What should we do to make it easier for people to build clients?

• Provide machine-readable descriptions of the service interfaces. These machine-readable descriptions can be used to generate human-readable descriptions. For instance, instead of generating an HTML table for your Gregorio tables, how about generating JSON? Then you can generate an HTML file that uses some JavaScript to format the result in an HTML table. Perhaps you can use it, once you've built a little client invocation stack, to build some dynamic callable objects which serve as proxies to the server (if you're lucky enough to be working in a dynamic language).
• Provide machine-readable descriptions of the data flowing over the wire. Not just the HTTP content, but query string parameters where appropriate.

If you can reflect on your service interfaces and data dynamically in the server, then you can generate all this meta-data reflectively as well.

Or if you really do want to do some code gen, and your client is able to load directly runnable code from your server *cough* JavaScript *cough* then it's easy to imagine that you could code-gen a client library dynamically on the server as well. I suspect that's actually overkill though.