Blogging Roller

JIRA finally gets its own REST API

Dave Johnson — Thu, 1 Mar 2012 09:20:30 +0000

JIRA's got a real REST API now:

REST easy with JIRA 5 | Atlassian Blogs: Now that JIRA 5 is out, let’s talk about one of my favorite features of this new release, JIRA’s new REST API. JIRA has supported remote APIs for many years with SOAP, XML-RPC, and JSON-RPC. However, telling developers that you support SOAP (and only SOAP) is like saying that you like writing applications with COBOL — it’s out of style. Today’s cool kids gravitate towards REST. It’s clean, simple, and highly portable across languages and frameworks.

And checkout the nice looking API docs, which look like they were generated by WADL-to-HTML.

An alternative to Atlassian's new API is the recently release Rational OSLC Adapter for JIRA, which allows you to do more sophisticated integrations with JIRA including delegated UIs for issue creation and selection.

OSLC Core v2 specification now FINAL

Dave Johnson — Wed, 1 Jun 2011 14:38:13 +0000

I've been working on the OSLC Core specification for about 1.5 years now as workgroup lead, and OSLC fits squarely under the "open web technologies" and Web Integration Patterns topics of this blog, so I'm blogging this happy news.

Here's the announcement From the OSLC Core Workgroup mailing list:

From: Dave Johnson
To: oslc-core (a) open-services.net, community (a) open-services.net
Subject: OSLC Core v2 specification now FINAL

Today [1], I'm very happy to announce that the OSLC Core v2
specification is FINAL.

The OSLC Core v2 specification [2] defines a set of REST and Linked
Data-based patterns, resources and protocols for integration of application 
and product lifecycle resources (ALM and PLM). It's designed to be the
foundation for all other OSLC domain specifications and there are now
three final OSLC specifications that are based on the Core, those
being the OSLC Change Management (CM) [3], OSLC Quality Management
(QM) [4] and OSLC Requirements Management (RM) [5] specs.

I'd like to thank all of the members of the OSLC Core Workgroup and
community for their hard work, critical thinking and ability to work
together in such a productive and pleasant way. Also, special thanks
to those OSLC domain workgroups who rebased their work on the Core and
development teams that provided excellent feedback along the way.

Thanks,
- Dave

--
David M. Johnson
OSLC Core Workgroup Lead
IBM Rational Software

[1] Move to final was proposed last week, along with a small set of
changes which have since been applied to the specification. 
[2] OslcCoreSpecification
[3] CmSpecificationV2
[4] QmSpecificationV2
[5] RmSpecificationV2

I really do have another Web Integration Patterns post on the way shortly, so stay tuned.

OAuth everywhere!

Dave Johnson — Fri, 6 Mar 2009 11:10:54 +0000

For my ApacheCon EU talk, which is now just a couple of weeks away, I'm going to talk about Shindig for Blogs and Wikis. I promised to show social features and OpenSocial Gadgets running inside Apache Roller and Apache JSPWiki (incubating). This post explains, at a very high level, how I got a Roller Gadget working, one that uses OAuth to call Roller and enables Roller to use OAuth to call back to the social network. It assumes you have a basic understanding of OpenSocial and OAuth.

Use case: posting Activities from Roller #

Specifically, what I want to show is a "Social Roller" Gadget that you can install into your Profile Page and that will post an Activity every time that you post a new blog entry in Roller.

Sounds simple, but I didn't realize just how much work it would take. To do it the right way, I needed OAuth everywhere! I needed OAuth Consumer and Provider support in both my Shindig-powered Social Network Server, that's SocialSite, and in my Blog Server, which of course is Roller. Unfortunately, when the layoff axe fell at Sun the SocialSite team had not finished OAuth support and Roller didn't have any OAuth support at all. Good thing is, SocialSite and Roller are open source and I had nothing better to do than to learn about OAuth and crank out some code. I'm not going to let a bunch of axe-wielding bean-counters stop me from keeping my promises.

How it works#

I now have complete OAuth Provider and Consumer support in SocialSite and Roller working and ready to demo. I'll post a screen-cast of the UI changes once I polish it up a bit (and finish my slides). For now, all I've got for you is a diagram that explains how the gadget interacts with SocialSite, Roller and OAuth to post activities to your profile.

Here's the deal. You install the Social Roller Gadget into your Profile Page within Roller. The gadget needs to talk to Roller so (#1) it calls Roller via the JS Container APIs. (Note that the blue indicates parts of the Social Roller Gadget.)

(#2) The container will work with the SocialSite Proxy servlet to add the right OAuth consumer keys, secrets and/or tokens to the request and will then send that request off to Roller. It must first (#3) negotiate with the OAuth Servlets in Roller. If you have not authorized the gadget to access your Roller account, then the container will show Roller's OAuth authorization page so you can hit the Authorize button, or not.

Once the gadget is authorized to access your Roller account, it will (#4) call the gadgetsetup.jsp page via HTTP GET to determine if you have enabled Activity posting. If you want to enable or disable, it will use an HTTP POST to tell Roller what you want.

The setup page will then (#5) call the Gadget Task to tell it to look out for your new blog posts and post an activity for each. The Gadget Task is controlled by Roller's cluster-friendly task management system and setup to run every minute.

Once you've enabled Activity posting, when the Gadget Task runs it will check to see if you have made any new posts and if you have, it will (#6) call the OpenSocial REST API to post an activity for each to your Profile. Negotiating with the OAuth Servlets as needed. And that's that.

What I didn't cover#

There are a lot of things I didn't mention and I hope to document some of them in the next week or so, while I'm still unemployed. Here's a quick summary of missing pieces:

How does SocialSite get the Consumer Key and Secret needed for calling Roller?
How does Roller get the Consumer Key and Secret needed for calling SocialSite?
How does the user authorize Roller's access to his Profile information in SocialSite?
When is OAuth support coming to the Roller trunk and can you use it for AtomPub?
How do I add my gadget to SocialSite so users can install and use it?

There are happy answers for all those questions, but that's all I've got time for today. I've got some slides to finish in a hurry.

The X-rated SocialSite API

Dave Johnson — Mon, 20 Oct 2008 10:48:38 +0000

Roy Fielding: I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today's example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

Ouch! As the author of the torrid (and pretty rough) Project SocialSite Proposal: Finalize Web Services APIs proposal that Roy calls out to sharply, I'd like to point of that, as I explained in a recent post, Project SocialSite is simply implementing and extending the OpenSocial API. OpenSocial includes both a JSON-RPC API and a REST API. SocialSite implements and extends them both. I never meant to imply that the JSON-RPC API is RESTful (and neither did the authors of the OpenSocial specifications). In fact, I renamed the proposal from "Finalize REST APIs" to "Finalize Web Services APIs" after I realized that OpenSocial would come in both flavors.

The proposal that I wrote outlined a way for Project SocialSite to hook into Apache Shindig (incubating), the Reference Implementation of OpenSocial,implement a couple of Shindig interfaces and thus gain support for both the OpenSocial REST API and the OpenSocial JSON-RPC API. The OpenSocial REST API does claim to be RESTful and I believe it is; it's based on AtomPub but includes some extensions for providing generic XML and JSON representations in addition to Atom format. The Project SocialSite REST API will extend that and will also be RESTful.

Shindig/Java internals diagram updated

Dave Johnson — Tue, 23 Sep 2008 16:09:52 +0000

A lot has changed since I did my first and even my second "how does Shindig/Java work" diagram. Believe it or not, there are now two separate web services protocols in OpenSocial and thus in Shindig. I'll explain that and then I'll share my updated diagram and synopsis of Shindig/Java internals.

NOTE: this post covers the social API implementation only and not the Gadget server portions of Shindig.

Here's what happened. There was a long discussion on the OpenSocial spec mailing list about the merits of REST vs. RPC for the OpenSocial web services APIs (e.g. here and here). I'm not going to characterize the two sides as the JavaScripty Gadgeteers and the XML-smokin' RESTafarians because that would be just plain silly. Long story short, neither side really "won" and so the latest rev 0.8.1 of OpenSocial includes two separate web services protocols:

The OpenSocial REST API, which is based on AtomPub but with support for XML and JSON formats in addition to Atom format XML. There is no support for batching of operations. (There was a proposal for RESTful batching, but it did not gain consensus.)
The OpenSocial JSON-RPC API where methods are called by HTTP POSTing JSON data and there is full support for batching of operations.

Seems a pity to have two separate protocols that serve essentially the same purpose, but thankfully there are a lot of similarities. For example, the JSON-RPC protocol methods are GET, POST, PUT and DELETE. And the JSON format used in the JSON-RPC protocol matches the one in the REST API. That makes things a little easier for implementers and if you use Shindig as the basis for your social network's OpenSocial implementation, it's even easier -- you implement one set of interfaces and you get support for both REST and JSON-RPC. Next, I'll explain how that works with my updated diagram:

And I'll explain by walking through the processing of one request; here's the walk-through (new stuff is highlighted in yellow:

1... A request enters Shindig via either the DataServiceServlet at /social/rest or the JsonRpcServlet at /social/rpc, which has a map of DataRequestHandlers (which it got from the HandlerProvider) keyed by the route that each handles. It's also got a pair of bean converters, which will come into play later when we need to convert outgoing POJOs to XML or JSON representation.

2... The Servlet creates a RequestItem, which parses the request for easy access later. The request item also has a pair of converters which can be used to convert incoming XML or JSON data into Java POJOs.

There are two different request items, one for REST RestfulRequestItem and one for RPC RpcRequestItem. The RESTful request item parses the incoming URL for parameters and treats data from a POST or PUT as typed data, to be automatically converted from JSON, XML or Atom into a Java POJO object from the SPI.

In the RPC case, everything is a POST and the request item grabs its parameters and the typed payload from the JSON object that was posted to the server.

3... The Servlet calls the appropriate handlers. If the request is a single request, then the Servlet looks up a DataRequestHandler based on the request's "route" (i.e. the first segment of URL's pathinfo). The Servlet calls the selected handler, hands it a request item. If the request is a batch request then the Servlet does the same as above, but in a loop collecting request items.

4... One of Shindig's three request handlers then handles the request and returns a ResponseItem or (plural) items containing the Plain Old Java Objects (POJOs) to be returned to the called. This is the point where incoming XML or JSON data is de-serialized to POJO form by a call to requestItem.getTypedParameter(). Shinding provides three DataRequestHandlers:

PersonHandler: returns Person objects with detailed profile information
ActivtyHandler: returns Activities of people or group, allows activity creation
AppDataHandler: returns Gadget data, allows Gadets to store data

NOTE: If want to add your own REST/RPC APIs to extend Shindig, as we are doing in SocialSite, you can do it by hooking in your own handlers. Use Guice dependency injection to hook in your own custom HandlerProvider, one that returns your own custom handlers.

5... The Shindig handlers call the Shindig Service Provider (SPI), which is defined by a set of interfaces with methods that return ResponseItems. There is a set of model objects, aka POJOS, shown in green that represent the different data types that can be returned by the REST or RPC APIs. The service implementations return these POJO objects and expect the Shindig infrastructure to automatically map POJO to either JSON or XML as appropriate.

PersonService: returns Person objects with detailed profile information
ActivtyService: returns Activities of people or group, allows activity creation
AppDataService: returns Gadget data, allows Gadgets to store data

NOTE: the SPI is where you hook in to Shindig if you want to expose your application's Social Graph data via the standard OpenSocial REST or RPC API. You implement these interfaces with code that calls your back-end to create, retrieve update and delete data. And you hook your implementation via Guice.

6... The handler returns a ResponseItem, which wraps one or a collection of POJOs. The Servlet may then write that response out or, in the batch case, continue to call handlers and collect more ResponseItems.

7...Servlet converts/serializes and returns ResponseItems. In the REST API case, once the handler, or handlers in the batch case, returns the response item(s), the DataServiceServlet calls the appropriate converter to serialize the item(s) to either JSON or XML format depending on what was specified in the 'format' request parameter.

And that's that...

Another vote for RESTful JSF

Dave Johnson — Tue, 26 Aug 2008 08:27:33 +0000

From the Seam Framework team's wiki page on JSF2 major issues:

The JSF2 expert group should work closely with the JSR 311 expert group to define overlapping integration points (unified configuration) and programming models, so that a JSF implementation can work seamlessly with a JAX-RS implementation. For example, a @Path annotated POJO should work as a JSF backing bean without any additional configuration. A JSF application programmer should be able to expose RESTful remote APIs easily.

Right on.

Via Matt Raible

re: How the Shindig REST API works

Dave Johnson — Mon, 11 Aug 2008 17:02:15 +0000

Here's a diagram I worked up over the weekend to explain Shindig REST API internals to my team mates. See the Project SocialSite blog for the full story.

RESTful JSF in the works?

Dave Johnson — Fri, 8 Aug 2008 15:52:58 +0000

JSF spec lead Ed Burns just pointed out that some of my Sun-internal comments about JSF have made it outside the firewall and into an issue on the JSF specification project:

On Wed, 19 Mar 2008, David M Johnson said:

I think the goal should be to make JSF applications RESTful by default, with proper use of GET and POST, i.e. only use POST when application data is changing, not for component state. Another goal should be clean, book-markable URLs that only carry path-info and parameters needed by the application logic.

That's easy and the default situation with Rails, Grails, Struts, etc. How hard would it be to redesign JSF along those lines? Would it require EJB2 -> EJB3 level changes to JSF?

I suspect work on JSF 2.0 is too far along for this kind of change now, but it's nice to hear that the idea of a truly RESTful JSF is at least under consideration.

Latest Links: Roller, REST and more

Dave Johnson — Mon, 21 Apr 2008 14:00:07 +0000

Skrocki's Blog: WOOHOO Sun Blogs sees its 100,000th blog post!!!
Pat Chanezon made the first post, not sure who made the 100,000th
Mark Fortner: how to publish to Roller via Google Docs
"Google Docs 'publish' feature allows you to publish a doc as a blog entry."
Chandra Chan: Using wbloggar 4 with JRoller version 3
"using the new version of w.bloggar version 4.03"

Jean-Francois Arcand: Jersey 0.7 released...with a tiny taste of Grizzly Comet Support
"gives us a couple weeks and we gonna have something really amazing"
Earthly Powers: Jersey 0.7 released
"many additions and clarifications to the API" plus Comet support
NetBeans 6.1 RC2: Let the IDE Do The Web Services Plumbing For You
"brings support for web services from Google, Amazon, Facebook and others"

ZDNet: Social networking will be biggest enterprise 2.0 priority by 2013
"smaller businesses arenâ€™t even considering, while the giants are diving in head first"
Move Over Lotus Notes, SharePoint is Filling Yer Shoes
"What Microsoft makes look easy â€” can quickly become a nightmare in the making"
Joshua Marinacci: know of any good forum software?
Comments suggest JForum, LifeRay message board and other Java options

colmmacc: AWS, AppEngine and the future of data
coping with the "fallout of using a planet instead of a hard-disk"
Search Guy: Minion open source search engine from Sun Labs
search "engine that ships with the Portal Server and Web Server"
Unit Structures: Introducing Freedom
"I find myself desperately searching out places where I can be network-free"

Latest Links: JSF vs. REST

Dave Johnson — Mon, 18 Feb 2008 13:27:08 +0000

I've been very happy with the choice of Struts 2 for Roller, but I still follow JSF because it's the Java standard. A couple of articles by Ryan Lubke about what's coming in JSF 2.0 got me thinking about JSF again.

Ryan Lubke's Blog: JSF 2.0 New Feature Preview Series, pt. 2.1: Resources
"Previous versions of JSF had no facility for serving resources"
Ryan Lubke's Blog: JSF 2.0 New Feature Preview, pt. 1: ProjectStage
"the JSF 2.0 EG has given a nod to Ruby on Rails' RAILS_ENV functionality"

One of my problems with JSF is REST. REST fans say JSF is inherently RESTless because every JSF request is a POST. JSF advocates say JSF can do GET and bookmarkable URLs if necessary and that's good enough.

Bill de hora on JSF and REST
"JSF is clearly not focused on or suitable for working in the REST style to the extent REST principles seem to be actively excluded from the design."
Gavin King on JSF and REST
"On these community sites that claim you can't build restful application with JSF. I mean it is total nonsense. It is not even remotely true."
Gavin's JSF bookmarkable URL example
In the comments thread of an anti-JSF story at The Server Side.

Fortunately, the plans for JSF 2.0 indicate that REST improvements are coming:

Java.Net TWik: JSF 2.0 Requirements Scratchpad
Mentions REST API (JSR-311) and navigation without using POST
JSR-314: JavaServer Faces 2.0
"Allow JSF application resources to be accessed via REST" and "Add support for REST (JSR 311)"

Unfortunately, it sounds like all they're planning to do is make it easier to create bookmarkable URLs and add some support for the JSF-311 REST API. Why can't the goal be to make JSF applications RESTful by default? Why can't JSF ensure that POST is only used when required by the application (not the framework) and JSF URLs are simple, clean and always bookmarkable.

Zero

Dave Johnson — Mon, 2 Jul 2007 09:28:53 +0000

IBM's project Zero has de-cloaked.

Project Zero introduces a simple environment for creating, assembling and executing applications based on popular Web technologies. The Project Zero environment includes a scripting runtime for Groovy and PHP with application programming interfaces optimized for producing REST-style services, integration mash-ups and rich Web interfaces.

Smells a lot like Phobos (see also Phobos Meets Atom, REST), but Phobos is focusing on server-side JavaScript first. Oh, and Phobos is open source. Project Zero is not.

"This community is an experiment in a new way to build commercial software, an approach we are currently calling Community-Driven Commercial Development. Community-Driven means that we want feedback, insight, suggestions, criticism, and dialogue with you, the users of Project Zero. This interaction will yield a better solution that is more targeted at the problems you have and a technology that truly delivers on its objectives. Commercial means that this is not an open source project."

Community-driven? Sounds like the community is a back-seat driver with freedom to complain but no access to the steering wheel, gas pedal or breaks.

Joe's Q&A: Do we need WADL?

Dave Johnson — Tue, 5 Jun 2007 17:57:22 +0000

Joe turns a #redmonk IRC chat-room discussion into an insightful Steven O'Grady style Q&A on REST, WADL, interfaces and APP. For the record, I still think WADL is going to be useful to many, but I think APP is going to be a whole lot more useful and it doesn't need or use WADL.

Update: Pat Meuller has more on the WADL question. Apparently, there were some interesting hallway discussions about about out at IBM RTP. I just caught the tail-end of that on IRC.

Friday Atom and REST links

Dave Johnson — Fri, 25 May 2007 22:30:40 +0000

A bunch of Atom and REST related links that I came across while catching up with my blog reading today:

Atom and LDAP sitting in a tree. Trey Drake has released his OpenDS based Atom store as an open source project on Java.net at http://atom.dev.java.net. It's a directory server distributed as a Java web application that supports both Atom Publishing Protocol (APP) and Lightweight Directory Access Protocol (LDAP).

Signing, encrypting and decrypting Atom. On IBM developerWorks, Nicolas Chase explains how "digital signatures and encryption can easily mesh with Atom data using the Apache Abdera API."

Google GData: A Uniform Web API for All Google Services. Dare Obasanjo praises Google for creating a single uniform and RESTful web services API for eight of its key services, the APP based GData API. He writes "not only is it now possible to create a single library that knows how to talk to all of Google's existing and future Web services since they all use GData. It is also a lot easier to provide 'tooling' for these services than it would be for Yahoo's family of Web services given that they use a simple and uniform interface."

RESTful web services support in Netbeans. Geertjan links to blog entries and a screen-cast that explain Netbeans 6.0 support for RESTful web services, including the early access JSR-311 REST API.

Generate code from your WADL REST API. Eduardo at The Aquarium links to Thomas Steiner who is making progress on a WADL editor and a generator, bringing WSDL-like code generation to RESTful web services.

The Apache Lucene GData server project

Dave Johnson — Tue, 15 May 2007 22:18:21 +0000

German Viscuso: Generally spoken GData provides a general interface to make information available even beyond a browser context by providing a single API that could be used to query, update, and index structured data anywhere on the web. Could GData become a simple and open replacement for all the proprietary communications protocols currently in use by database vendors?

Interesting thoughts. I've heard about the Atom Publishing Protocol (APP) based Lucene Web Services API, but I hadn't heard about the Apache Lucene GData server project. Atom protocol is moving fast, especially considering the fact that it's not finished.

RESTful Web Services, by Richardson and Ruby

Dave Johnson — Sat, 12 May 2007 15:47:23 +0000

Leonard Richardson and Sam Ruby's new book RESTful Web Services is now available. It was one of the best sellers in the JavaOne bookstore this year, so congrats to Leonard and Sam. It sold out before I was able to get a copy; Rajiv bought the last one in the store.

APP and OpenID at JavaOne

Dave Johnson — Mon, 7 May 2007 14:43:56 +0000

Trey Drake: How do you demo a directory server? Build cool apps around it. To that end, we've built an Atom/APP server, a lightweight OpenID server, a blogging and "twitter" like app - all powered by OpenDS. Drop by our booth (Glassfish alley at CommunityONE and .org section of the pavilion during JavaONE). Ludo and I will introduce OpenDS and show off the demos in two talks; today at CommunityONE at 5PM and Wednesday at 1:30 in the CommunityCorner.

Very cool. I'm not going to be the only one talking about Atom protocol at JavaOne. I'll have to stop by the CommunityCorner, that sounds too good to miss.

Propono 0.5 released

Dave Johnson — Mon, 23 Apr 2007 15:32:10 +0000

ROME Propono 0.5 is a minor bug fix release of Propono. You can get the release files and updated Javadocs from the Propono 0.5 release page.

@JavaOne: Beyond Blogging: Feeds in Action

Dave Johnson — Wed, 4 Apr 2007 17:32:34 +0000

As promised here's some more info on my JavaOne 2007 session. It's based in part on the Beyond Blogging presentation that I presented to a tiny audience at the local Tri-XML conference last year. Tim Bray didn't attend my talk, but he read the slides and called them "the single best introduction and overview I've ever seen about feeds and syndication and RSS and Atom and all that stuff." I shouldn't brag. Had he attended the talk he might have had an entirely different opinion, who knows. Anyhow, the presentation has been updated, stream-lined and large portions rewritten to cover ROME and ROME's new Propono sub-project. Here's the outline:

The web is bloggy
    Blogging, XML and web services
    Feeds on the web today
    Feeds as an integration technology
    WS Death Star
Understanding RSS and Atom
    The birth of the RSS
    The RDF fork: RSS 1.0
    Elements of RSS 1.0 (abridged)
    Feed Extension Modules
    The simple fork: RSS 0.92 â€“ RSS 2.0
    Elements of RSS 2.0 (abridged)
    RSS limitations
    Atom Publishing Format
    Elements of Atom (abridged)
    RSS and Atom feed family tree
Consuming feeds with ROME
    It's just XML
    ROME RSS/Atom feed utilities
    How does ROME work?
    ROME SyndFeed model
    How to fetch feeds
    Fetching a feed with ROME Fetcher
Producing feeds with ROME
    Serving feeds: generate XML
    Use your favorite XML tools or...
    Generating Atom with ROME
    Serving feeds
    Cache cache cache
    Serving Atom with ROME
    Feed auto-discovery
    Serving valid feeds
Publishing with ROME Propono
    Atom Publishing Protocol (APP)
    What does APP do?
    How does it do all that? The REST way
    APP Service Document
    An Atom collection <feed>
    Getting an APP collection - with paging
    ROME Propono
    ROME Propono Atom Client API
RSS/Atom trends
For More Information
Summary
Q & A

And for the folks who've written to me about Propono, the new ROME subproject devoted to publishing via Atom protocol (and the MetaWeblog API): I hope to commit the code to ROME and starting blogging about it this week.

Latest links: March 21, 2007

Dave Johnson — Wed, 21 Mar 2007 22:42:13 +0000

David Van Couvering: Why use Atom Publishing Protocol for REST?
"Why not just use HTTP and JSON and have done with it?"
Max Ross: Ode to Hibernate (and Shards)
"Shards, a framework that adds support for horizontal partitioning (or in Google parlance, "sharding") to Hibernate Core"
James Snell: Don't Panic
"it is possible to get very far with nothing but the base APP protocol."
Elias Torres: Is AtomPP for or not for blogs?
"we'll probably have to do some good amount of extra work in defining how blogging clients will interact with a blogging service"
Rob Yates: Atom Publishing Protocol - not enough for blogs?
Rob wants a guide that "allows blogging clients to be interoperable with blogging servers"
Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt
Roy Fielding: "the sky is not falling, and AtomPP implementations will interoperate just fine"

Sun Web Developer Pack R1 with RSS and Atom goodies

Dave Johnson — Mon, 12 Mar 2007 21:20:29 +0000

The Sun Web Developer Pack (SWDP) finally uncloaked today, so I can talk a little more openly about what I and my Java EE co-workers have been working on. You can get the full scoop at the SWDP site, but basically SWDP is a bundle of technologies to help developers build "Web 2.0" or next-generation web applications on the Java platform. Ajax, scripting languages, REST and of course RSS/Atom are all part of that. The RSS/Atom bits are ROME 0.9 (Beta), Blogapps 2.0 (Early Access) and a ROME-based Atom Server kit based on code from Roller. There are also example Atom server implementations in the REST API and Phobos components of the pack.

I'm pretty excited that we're putting some resources behind ROME and that both ROME and Blogapps are part of SWDP R1, but I'm even more excited about the next release. In R2 we'll drop the Atom Server Kit and Blogapps BlogClient and we'll replace them with ROME Propono a brand new Atom protocol client and server library that we're getting ready to contribute to the ROME project.

I haven't had a whole lot of time to experiment with the various components in the pack, but I have played with Phobos and I think it's pretty compelling. Phobos is a "lightweight, scripting-friendly, web application environment." It's not just for creating server-side JavaScript applications, but that's the angle the I find interesting. So many developers are creating JavaScript/Ajax applications these days that working in JavaScript on both client and server-sides makes sense -- especially when you can debug into JavaScript code in your IDE as you can with the Netbeans Phobos module. Also note that the jMaki Ajax components work with JSP, PHP and Phobos -- jMaki and Phobos look like a winning combination.

javax.ws.rest

Dave Johnson — Wed, 14 Feb 2007 10:24:20 +0000

That's big news. A standard Java API is coming for building REST based web services. If you're an expert in REST, you can participate in it's development by signing up for the expert group. Apache, BEA, Google and Jerome Louvel (the RESTlet guy) are on-board. Here's the intro from the JSR:

JSR 311: Java (TM) API for RESTful Web Services: This API will enable developers to rapidly build Web applications in Java that are characteristic of the best designed parts of the Web. This JSR will develop an API for providing REST(Representational State Transfer - See reference to Roy Fielding's dissertation in section 3.1) support in the Java Platform. Lightweight, RESTful approaches are emerging as a popular alternative to SOAP-based technologies for deployment of services on the internet. Currently, building RESTful Web services using the Java Platform is significantly more complex than building SOAP-based services and requires using low-level APIs like Servlets or the dynamic JAX-WS APIs. Correct implementation requires a high level of HTTP knowledge on the developer's part.
This JSR will aim to provide a high level easy-to use API for developers to write RESTful web services independent of the underlying technology and will allow these services to run on top of the Java EE or the Java SE platforms. The expert group will investigate whether a subset of the API can be made used with Java ME. The goal of this JSR is to provide an easy to use, declarative style of programming using annotations for developers to write REST ful Web Services and also enable low level access in cases where needed by the application.
RESTful Web Services is a relatively new area in the industry and there are still a lot of unknowns in this space. For example, a key aspect of RESTful Web Services is for the service to be stateless. However, this often requires the developer to produce boiler-plate state restoration code that could be avoided with state-aware API help. We expect the expert group to be an active and engaged group of people participating to prioritize and help drive issues to achieve the end goal of a developer friendly API.

Here are a couple more links about the new JSR:

Elliote Rusty Harold is not exactly positive, saying "this is like asking Karl Rove and Dick Cheney to write the Democratic Party platform" but concludes with a call for participation: "are there any JSR members here who might join the working group and bring some sanity and actual REST experience to the development of the eventual specification?"
Jerome Louvel explains the idea of REST annotations and explains that implementations will be possible with JAX-WS, Servlet API or Restlet API.
Dan Diephouse says "This is excellent news - Iâ€™m glad to see people are thinking more seriously about RESTful services on Java" and "Expert group members may be interested in checking out the previous work Iâ€™ve done on Java REST annotations"
Brian McAllister: says the JSR sounds like another case where "reasonably good developers trying to design software for presumed-incompetent developers which will in fact be used unhappily by basically competent developers."
Mark Hadley addresses some of the concerns raised above and provides an interesting code example showing the REST annotations in action.
Pete Lacey: "Initial thoughts: 1) Cool! 2) The servlet API is not ideal, this is needed. 3) I hope they donâ€™t screw it up (see JAX-WS)."
Steve Loughran: "I don't have the faintest clue what a REST API should look like, except that it must not look like JAX-RPC/JAX-WS"
InfoQ thread: summary of news and three comments as of Thursday
Paul Sandoz: "I have been wanting to work on such an API and implementation for about 5 years! [...] Now the Web zeitgeist is back and so are we :-)"

New Atom protocol spec draft and Queen City planets

Dave Johnson — Wed, 27 Dec 2006 16:50:19 +0000

Joe Gregorio announces a new Atom Publishing Protocol Spec (draft #12) and he says it might end up being the final. I guess it's time for a new Blogapps release with APP draft #12 and ROME 0.9 support.

Plus, Joe has put together a set of new planet sites for towns in the Charlotte, NC area; all based on feeds from Google Base, Google Blogs, Google News, Craigs List, Flickr and the Weather Service. The sites look useful, but the ads combined with the minimalist design make them look a little spammy on first glance. Perhaps a short "about this site" paragraph is in order.

New book on REST Web Services

Dave Johnson — Tue, 7 Nov 2006 10:14:09 +0000

To design a website you need to know about HTTP, XHTML, and URIs.
To design a web application you need to know about HTTP, XHTML, and URIs.
To design a web service you need to know about XML, SOAP, WSDL, UDDI, WS-Policy, WS-Security, WS-Eventing, WS-Reliability, WS-Coordination, WS-Transaction, WS-Notification, WS-BaseNotification, WS-Topics, WS-Transfer...
What happened there?

Leonard Richardson and Sam Ruby are writing a book on REST Web Services and they're going to develop it in the open on their blogs. If you care about web services of any kind, you're going to want to follow along.

Atom protocol and WADL

Dave Johnson — Fri, 28 Apr 2006 16:47:44 +0000

Via The Aquarium I see that Mark Hadley's work on Web Application Description Language (WADL) is now a Sun Technical Report. WADL provides a way to describe a REST based web application or service so that tools can discover services, generate proxies, etc. As I understand it, WADL is to REST as WSDL is to SOAP.

There's also something new since the last time I looked at WADL. Mark has added a section on the Atom protocol and examples that show how to use a WADL file to replace an Atom introspection document. Looks like good stuff to me. If you need an introspection doc for your REST based web service, why not use WADL?

Via Google, I found that there's also a WADL presentation on-line.

Destructive GET

Dave Johnson — Fri, 6 May 2005 17:13:43 +0000

Beware the Google Web Accelerator. It will wreak havoc on the web applications that you use ~~(Roller included)~~. Problem is, in most webapps HTTP GET changes things (even though it shouldn't). Read all about it on <a href= "http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html">O'Reilly Radar. I don't understand this. Google employs a hell of a lot of very smart people. How did they let this one slip by?

Update: I just reviewed the Roller UI and found that, at least for deletes, we do the right thing. The pattern we follow is to use a delete link (which causes a GET), but that sends you to an "Are You Sure" page which uses a POST to do the actual delete -- so Roller is probably safe from the Google Web Accelerator.