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.
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.
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 , I'm very happy to announce that the OSLC Core v2 specification is FINAL. The OSLC Core v2 specification  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) , OSLC Quality Management (QM)  and OSLC Requirements Management (RM)  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  Move to final was proposed last week, along with a small set of changes which have since been applied to the specification.  OslcCoreSpecification  CmSpecificationV2  QmSpecificationV2  RmSpecificationV2
I really do have another Web Integration Patterns post on the way shortly, so stay tuned.
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.
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. How did that happen you wonder, well read on...[Read More]
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.
Via Matt Raible
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.
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.
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.
Fortunately, the plans for JSF 2.0 indicate that REST improvements are coming:
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.
"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 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.
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."
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.
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.
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.
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.