Sunday, June 27, 2010

2010-06-27 Sunday - REST Resource Links

I've spent some time doing a bit of research this weekend on RESTful architecture patterns, and wanted to share the links that I found interesting...not all of the articles are accurate reflections of valid REST approaches - but I found value in considering their dissenting opinions, and so might you.

If you are looking for a short and succinct article to get clarity on REST - you can do no better than reading Roy Fielding's commentary on the subject here:

Or, if you have the time and inclination...reading his original PhD disseration...

Roy Fielding's Architectural Styles and,the Design of Network-based Software Architectures

Rohit Khare's dissertation is also worth reading:
Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems

Proceedings of the First,International Workshop on,RESTful Design, WS‐REST 2010

JSR 311: JAX-RS: The JavaTM API for RESTful Web Services

InfoQ: A Brief Introduction to REST

RESTful Web services: The basics

Should We Compare? SOAP VS REST

Why understanding REST is hard and what we should do about it – systematization, models and terminology for REST

InfoQ: REST and transactions?

REST for Java developers, Part 1

How [someone] explained REST to a SOAP pro

When to Use RESTful HTTP

Designing SOA in a RESTful way

"nine-part dialogue with an imaginary eBay Architect, accessible discussion of the REST vs. SOA issue"

REST Resource Links...

RETRO: A Consistent and Recoverable RESTful Transaction Model


With REST becoming a popular paradigm for Web services, more and more use cases are applied to it, including some that require transactional guarantees. We propose a RESTful transaction model that satisfies both the constraints of transactions as well as those of the REST architectural style. We provide formal proof of consistency and recoverability in the proposed framework and show the robustness of its properties in the presence of concurrent transactions. 

RESTful Web services with Apache Wink, Part 1: Build an Apache Wink REST service

RESTful Web services with Apache Wink, Part 2: Advanced topics in Apache Wink REST development

SOAP and REST: Choosing formal and informal Web services for,CICS integration

How to Secure REST and JSON

Credit Cards, Transactions, and REST

Fomenting unREST : Is RESTfulness a semantics game ? Why does REST require statelessness ?

REST Design Pattern

PROPOSAL: Handling Asynchronous Operation Requests

RESTful Transactions
(note: this is something that Fielding strongly disagrees with)

Yahoo Groups >  REST Discussion Mailing List

ERP/2.50/Developers Guide/Concepts/XML REST Web Services

Dan Diephouse (of Mule Source) presentation on REST,%20Reliable,%20and%20Secure%20RESTful%20services.pdf

RESTful Casuistry


Don Box (on the pragmatic considerations of REST vs. SOAP

InfoQ: xTim Bray on Rails, REST, XML, Java, and More (October 11, 2006)

How do you see REST replacing a lot of the functionality that the WS* specs are providing like security transactions, choreography?
"Well, that's a good question. I think that the vast majority of operations on the web right now are GETs, you know, information fetch and a vanishingly small, but important proportion of updates. And to the extent that you can model your system in what I call a web style, where you have a lot of nouns, a small number of verbs, and you clearly distinguish between idempotent, safe operations and things that change the state, you can really go a long way with that pure web style, REST approach. If you really need deeply reliable complex transactions with multi-phase commit and all that stuff, I'm not sure the Internet is a very good channel for doing that. I think you'd really like to do that kind of thing behind the firewall in an enterprise environment. If you're actually going to operate across a heterogeneous large scale network, it would really be much better if you could possibly do things in the web style, which is: "I'm going to send you a package of information with everything that's needed to accomplish this transaction and you're going to come back to me and say if that worked or didn't, which is reliable." Where things start to get weird is where you have to have intermediaries, multiple machines involved in executing some transaction. The WS* stack does have a bunch of proposed, unstable, in-motion drafts for doing reliable transactions and so on across the network that are very highly unproved in practice. At the moment, if I'm actually writing a high volume of transaction processing system, I would probably prefer to do it the old-fashioned way, by talking to Oracle or you know, however you do it. Let's not kid ourselves that the WS* guys are actually offering real solutions in the space of transaction processing, right now, today, it's all theory."

Apache Wink
Apache Wink is a simple yet solid framework for building RESTful Web services. It is comprised of a Server module and a Client module for developing and consuming RESTful Web services.
The Wink Server module is a complete implementation of the JAX-RS v1.0 specification. On top of this implementation, the Wink Server module provides a set of additional features that were designed to facilitate the development of RESTful Web services.
The Wink Client module is a Java based framework that provides functionality for communicating with RESTful Web services. The framework is built on top of the JDK HttpURLConnection and adds essential features that facilitate the development of such client applications.

Microsoft WCF Interoperability

JavaWorld REST articles...
The Web Services Test Forum in an open and free community where developers and customers can perform interoperability testing and discuss issues surrounding the application of Web Service-based technologies. Web Services are machine-to-machine communications using HTTP, REST, SOAP or any other internet focused technology.

No comments: