Let me expound a bit on "simple", since Sam referenced me.
I consider myself a Ruby n00b.
I'm very familiar with HTTP.
I'm pretty familiar with AtomPub, and the Blogger posting interface is basically AtomPub-ish.
Most of the time spent writing the feedBlogger.rb script translating the pseudo-code in my head into Ruby. Also figuring out the ClientLogin protocol. The Blogger Data API Reference Guide was all I really needed to do the business logic. Not much there, but there's not much to know, assuming you're already familiar with Atom and AtomPub.
So keep in mind, this is fairly low-level code, executing HTTP transactions pretty close to the metal, from someone familiar with doing that. And it's a one-off program, didn't worry about error checking, caching, etc. Things that a program which isn't a one-off would like have to concern itself with.
If you're lucky enough to not be working in Ruby, you might have gotten by with one of the Google Data API Client Libraries, available for Java, .NET, PHP, Python, Objective-C (???), and JavaScript. Not sure if you could really do what I did, with those libraries or not, since I couldn't use them, so I didn't even look at them.
Now, as a thought experiment, let's consider if the Blogger API was actually WS-* ish rather than RESTful.
In theory, I could take a WSDL description of the API, and use it with a dynamic WSDL/SOAP library, if one exists for Ruby (I know one exists for PHP).
Or I could generate some stubs in Ruby for that I could call as functions, assuming there is a stub-generator program available for Ruby.
Or knowing HTTP pretty well, as well as SOAP (not much there), as well as being able to translate WSDL into an HTTP payload because I'm familiar with THAT story, I could have written it in a low-level style as well.
The problem with the first is the first option is dealing with a thick runtime stack that I might have to debug because it's doing a lot of stuff. The typical problem is dealing with the XML payloads; getting all the data generated the way the server expects it. I've had to deal with that many, many times over the years.
The problem with the second is that there's additional stuff I have to do, and maintain, for my simple little program. Instead of just a script, I'd have to keep the WSDL, the build script to generate the stubs, and the stubs themselves. And even then I'm still left with a thick runtime library I might have to debug (see paragraph above).
The third option is just more work I'd have to do, and generally yuckifying the client program even more.
However, let me throw a little water on the REST fire. The Google Data API Client Libraries also suffer some of the same issues with WSDL. In particular, while I think people have the impression that RESTful clients can get by with just a decent HTTP library, the fact of the matter is, that's too much for some folks and having client libraries available is a nice thing to have. Which I will have to maintain with my programs.
And I did have to do some squirrelly stuff with the XML payload I was sending the Blogger; bolting the Atom xmlns onto the entries; there's probably a cleaner way to do this, so it might just be my unfamiliarity with REXML.
The big difference, to me, is that REST is less filling, as opposed to tasting great; ie, there's still a fair bit of highly technical skill needed to use this stuff, there's just a little bit less with REST compared to even simplistic WS-* WSDL/SOAP usage.
2 comments:
Pat,
Did you really mean to say "If you're lucky enough to not be working in Ruby,..." or did you mean unlucky?
I meant what I said. Look at the context; Google doesn't provide it's "wrapper library" for Ruby, though it provides it for many other languages. So, if you're working in Ruby, you're out of luck when it comes to being able to use their wrapper library.
Taken more broadly, I suspect a lot of folks who are using Ruby feel lucky to be able to use it. Especially if they're getting paid. for it. Came across loud and clear at RubyConf, almost embarrassingly so. I certainly enjoy it.
Post a Comment