Dave W points to Strangeberry, a startup that are doing a Java rendition of Rendevous.
“Interesting!” I think, as I go to their site and browse the founders’ resumes, where I find something rather disturbing. What I find is that various US Patents are being paraded. These patents seem to be predominately for software, methodologies, rather than inventions. Picking one at random, US6226654: Web document based graphical user interface – this seems to be using specific web technology components (HTML forms and graphics, for example) for exactly the use they were originally intended (GUI-in-browser). How the heck can you patent that?
Call me naive, call me an old fogey, but I do question the use of patents for programs and applications of software. At least the Strangeberry people aren’t trying to keep them a secret (in fact, quite the opposite!)
In the swirling mass of memes surrounding web services (whatever they are) it’s sometimes easy to forget that REST is an architectural style, an approach, rather than something that you install or debug. If nothing else, it’s become useful as a framework in which I can think more clearly about web-based projects and their interfaces. Thinking in terms of a limited number of verbs (methods) with well-defined and widely understood semantics, combined with a set of ‘objects’ (represented by URIs) certainly helped me come up with a clear idea of what I should code, and how it should appear to the outside world, in a couple of recent projects.
What’s really interesting is that a pattern is emerging. The interface description table in my ‘working notes’ (aka final documentation :-) that I’ve written to describe the details of the latest project bear a remarkable resemblance to the table in the RESTful RT experiment and also the one in Joe‘s RESTlog interface. For each interaction, they each roughly show:
- the HTTP verb
- the URI
- what the payload to be sent is (and its content-type) if any
- what the expected response is (HTTP status and pertinent headers)
- what the payload to be expected back is (and its content-type) if any
- what possible error responses there might be
Incidentally, Piers (my partner in code crime) has just written about the client-end of one of the RESTful projects at work.
I discovered a nice RESTful bonus when doing the documentation too – I could link directly to the URLs of some of the services from within my (HTML/Wiki-based) documentation, to show examples. That’s turning out to be very useful.
Jon Udell wrote about whitelisting and ChoiceMail earlier this month, and rightly pointed out that such mechanisms were in some ways evidence that in trying to combat UCE we were losing the general efficacy of email.
I just read (via Der Schockwellenreiter) about another potential assault (albeit seemingly well-meant) on the same. Wired reports on a charging plan for spammers, with mechanisms that would allow genuine emails to get through.
I don’t know what the answer is. For now, I’m happy, having installed the excellent SpamAssassin and enjoying virtually spam-free email bliss.
A (slightly) belated congrats to Ben on the publication of his book, Content Syndication with RSS. Just in time for my Christmas list. Having shared a similar experience I can appreciate the effort he has most certainly put in. Well done Ben.
After a rather longer-than-expected hiatus (I’ve been soaking up some of my online / technology saturation with some good old fashioned cooking, baking and sudden interest in antiques) I’m back in front of the keyboard.
Lots to catch up on indeed. Seems the extended community continues to be busy, innovative, and still rather passionate about things.
Anyway, as a starter for ten, I’ve dusted off a little abandoned project that I started shortly before OSCON this year and talked about it a bit there (on RESTifying RT). I’ve written up a few notes with a view to (a) crystallizing my thoughts and (b) thinking through the API I had (and bits I’ve added) so I can write a cleaner implementation. Maybe.