dretblog

Action URIs

anybody doing non-trivial things with REST sooner or later runs into interactions beyond the simple CRUD (create/read/update/delete) operations. there often are cases where operations might be tied to a specific resource (or mainly to that resource), and then the question is how model this in a RESTful way. a pattern that is seen frequently is the action URI, which is a URI that specifically represents one action on one resource.

for example, if there is an open order http://example.com/order/42, then the payment action will be represented at the URI http://example.com/order/42/payment. clients will interact with that by using either PUT or POST (PUT seems to be the preferred way) to submit a payment.

this clearly works, as demonstrated by many existing APIs, but is it really the best or only way of doing it? there are some issues with this design:

1. no linking: if this is just a payment service, why not use http://example.com/order/payment instead and have a payment media type that links to the order being paid? that would not only make the payment resource a more reasonable interaction point (it's basically like a cashier accepting many different things to be paid for), it also would allow for richer functionality such as paying for multiple orders (simply link to all the orders you're paying for) or even paying for third-party orders (simply link to these 3rd-party orders).
2. contrived resource model: if the action indeed is bound to a single resource (in contrast to the potentially more general action mentioned in issue 1), then why is it a resource? it seems that the interaction taking place is to submit a state change to the actual resource, and then that resource is changing state (from awaiting payment to paid) as a result of that interaction. what is the reasoning behind turning the payment into an action, and why is it significantly better than the dreaded just embed action=payment in URI query parameters anti-pattern?
3. not media type centric: if payment is done using a payment request, then there has to be a self-describing document conveying the payment data. this could be submitted to a general payment resource (as described in issue 1) or to the resource itself (as described in issue 2), but there really does not seem to be a good reason why it would need to be submitted to a specific URI just minted for that particular operation on that particular resource.

please keep in mind that even if you would use a general-purpose payment URI or POST a payment to the order URI, clients would still only be linked to the payment URI when payment would be a state change permitted by the server. as usual, a rel="payment" link would only be included if paying was an option, and the only difference to the resource-specific action URI approach would be that it would point to either a general-purpose payment URI, or to the URI of the order accepting the payment media type.

after a quick but non-representative look at some books and APIs, it seems to me that the resource-specific action URI is a pretty common pattern, and i would be interested in opinions about the alternatives, and also whether people have looked at all these patterns and have made decisions between them because of constraints that made one pattern a better fit that the other. as usual, there are many ways to solve a given problem, but the resource-specific action URI may be one pattern that could be replaced by others, at least in some scenarios.

Workshop on RESTful Design 2012 (WS-REST 2012): Call for Papers

Third International Workshop on RESTful Design (WS-REST 2012)

Abstract Submission Deadline: 3. February 2012
Call for Papers: http://ws-rest.org/2012/cfp

The Third International Workshop on RESTful Design (WS-REST 2012) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.

Background

Over the past years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the traditional research and academic community. Mailing lists, forums and developer communities have seen long and fascinating debates around the assumptions, strengths, and weaknesses of these two approaches. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.

This third edition of WS-REST, co-located with the WWW2012 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:

• Applications of the REST architectural style to novel domains
• Design Patterns and Anti-Patterns for RESTful services
• RESTful service composition
• Testing RESTful services (methods and frameworks)
• Inverted REST (REST for push events)
• Integration of Pub/Sub with REST
• Performance and QoS Evaluations of RESTful services
• REST compliant transaction models
• Mashups
• Frameworks and toolkits for RESTful service implementation
• Frameworks and toolkits for RESTful service consumption
• Modeling RESTful services
• Resource Design and Granularity
• Evolution of RESTful services
• Versioning and Extension of REST APIs
• HTTP extensions and replacements
• REST compliant protocols beyond HTTP
• Multi-Protocol REST (REST architectures across protocols)

All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on lessons learned rather than describing an implementation.

Original papers, not undergoing review elsewhere, must be submitted electronically in PDF format. 

Easychair page: http://www.easychair.org/conferences/?conf=wsrest2012

Important Dates

• Abstract Submission: 3. February 2012
• Paper Submission: 10. February 2012
• Notification of Acceptance: 8. March 2012
• WS-REST 2012 Workshop: 16. April 2012

Program Committee Chairs

• Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
• Erik Wilde, EMC, USA
• Rosa Alarcon, Computer Science Department, Pontificia Universidad de Chile, Chile

Program Committee

• Jan Algermissen, Nord Software Consulting, Germany
• Subbu Allamaraju, Yahoo Inc., USA
• Mike Amudsen, USA
• Bill Burke, Red Hat, USA
• Benjamin Carlyle, Australia
• Stuart Charlton, Elastra, USA
• Duncan Cragg, Thoughtworks, UK
• Cornelia Davis, EMC, USA
• Joe Gregorio, Google, USA
• Michael Hausenblas, DERI, Ireland
• Rohit Khare, 4K Associates, USA
• Yves Lafon, W3C, USA
• Frank Leymann, University of Stuttgart, Germany
• Alexandros Marinos, Rulemotion, UK
• Ian Robinson, Thoughtworks, UK
• Sam Ruby, IBM, USA
• Richard Taylor, UC Irvine, USA
• Stefan Tilkov, innoQ, Germany
• Steve Vinoski, Verivue, USA
• Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

WS-REST Web site: http://ws-rest.org/2012/
WS-REST Twitter: http://twitter.com/wsrest2012
WS-REST Email: ws-rest@lists.berkeley.edu

Creating Resources with GET/PUT

creating resources the RESTful way can be done with either PUT or POST, with PUT expecting that the URI of the created resource is known in advance (by the client issuing the request). semantically, the difference is that PUT is idempotent and thus can be repeated safely, whereas POST is non-idempotent and thus cannot be repeated. a PUT can be repeated because after creating a resource, a repeated PUT will simply overwrite the resource with the same representation, whereas a POST always is directed towards some factory resource, and thus repeating it would create a duplicate, which should be avoided.

in many cases, clients do not know the URI of the new resource, so the PUT approach cannot be used. the problem with the simple POST model is that clients have a hard time figuring out what to do when the POST request fails (e.g., the HTTP library says something went wrong). did the request make it to the server and cause a resource to be created? or did the request fail before that and the client could retry the POST? HTTP semantics say that POSTs cannot be repeated, so what now?

this is where people came up with the POST/PUT pattern. clients POST to a factory resource, but mostly in an attempt to get the URI of a new resource. a often useful side-effect of this pattern is that the server can return a template for the resource, allowing a client to understand what is expected. after the client has received the URI of the new resource, it PUTs the actual data there, and the important observation is that this PUT request can be safely repeated if it fails, because of its HTTP semantics.

what this does is simply push complexity around. instead of having to deal with possible duplicates being created, the server now has to deal with possible templates that were never populated. in many scenarios, this latter task is easier to do that the former one, it's essentially garbage collection and the server can clean up all resources that were created as a result of a POST, but were never populated with a subsequent PUT. if a client waits for an absurdly long period of time and then attempts to PUT to a resource that was garbage-collected, then it's up to server logic to either keep track of all URIs ever minted (which might get expensive), or just use URIs that are very unlikely to collide. in either case, the server would let the client know that the URI is gone, and that a new one should be requested by POSTing to the factory.

so far, this is just what people have been doing for a while already. as a new twist, what if the creation of a resource on the server is actually a fairly heavy-weight operation, because of all sorts of bookkeeping and retention mechanisms built into the persistence layer? creating a resource before it has been populated ideally should be avoided, because garbage collection is not as easy; as soon as a resource has been created, a lot of repository data is being created and cannot be deleted anymore.

the question i have been very slowly getting to thus is the following: in such a scenario, what about issuing a one-time token as a result of an initial request, which allows the client to PUT to that URI. but only if that PUT happens, the actual resource will be created in the repository. the token is just a place-holder, and the URI of the actual resource depends on the creation of the repository-level URI. in that case, the first PUT will be accepted, but will result in a 303 response that redirects to the cool URI. a second request to the token URI should result in a redirect as well, so that clients know that this token has been used.

there are two ways how the tokens can be associated with the cool URIs. the REST layer could maintain a list of token/persistent URI pairs, or the repository itself could have a field for each resource that keeps track of the token from which a resource has been generated. fast look-up is important, but can be done in either case. extending the repository model probably is the better way to go, but may not be possible in all cases. it is important to notice that tokens only need to be tracked once they have been used (i.e., something has been PUT there), before that, all that is needed is a token scheme that makes collisions highly unlikely (such as time stamp + client IP + random string).

here is the proposed sequence of steps in this scenario:

1. clients GET the template and a token from the factory resource. since this operation does not change server state, it is safe and idempotent and it is possible to use GET.
2. clients PUT to the token URI, at which point the server creates and populates the resource at the repository level, and keeps track of the token from which the resource has been created. the server responds with a 303 (See Other) response, indicating the persistent URI of the resource.
3. subsequent requests to the token URIs are handled with a 301 (Moved Permanently) response, telling clients that the token URI should no longer be used, and that a persistent URI is now available.

if the initial GET fails, it can be repeated safely, because it does not change server state, and thus is safe and idempotent. if something goes wrong with the PUT, it can be repeated, but if the server receives a repeated request, it will redirected with a 301. as soon as the resource has been created and the persistent URI is established, future interactions with the resource work as usual.

what are the main benefits of this approach?

• the factory GET allows the server to supply a template, and tell the client where to direct requests for creation. since the server is providing the URI, we can use PUT requests for creating the resource at this known URI. this initial step is stateless on the server side.
• the token-based creation allows the server to delay persistence-layer creation until something has been PUT by the client. the tokens are one-time PUT only, and after that they respond with 301. this approach scales with the number of resources, not with the number of clients, and usually is simply one more attribute in the persistence layer.

any feedback on this pattern is very welcome. has it been used somewhere else? does it seem to introduce problems not discussed here? is there a simpler way of handling the same scenario?

Grand Canyon Rim to Rim to Rim

after running from the north rim of the grand canyon to the colorado river and back three years ago, doing the whole thing (north rim to south rim and back or reverse) has been on my bucket list. this year i finally found the time and some people to join me on that adventure, and very fittingly, we did it on may 21st, the day the world was supposed to end (which disappointingly did not happen, but we still have high hopes for october 21st). on the final climb to south rim, it actually would have been very convenient to be lifted to the heavens, but unfortunately we had to do all the climbing ourselves.

after looking at the trails and the weather the day before we got there (picture [1]), everything looked fine, and we decided to start at sunrise, so that we wouldn't have to to the descent with headlamps. our was to use the bright angel trail from and to the south rim (less steep and water midway, as opposed to the south kaibab trail), and the north kaibab trail at the north rim (there is no other option anyway). when we arrived at the bright angel trailhead, we were greeted by the most spectacular sunset when we arrived at the rim at 5am [2], and after the obligatory photo [3], we started running at 5.15. getting to indian garden was surprisingly quick and easy, and this was our first short break to eat and drink. looking back up to the south rim, it was already lit by bright sunshine and the moon was hovering above it [4]. the thought of having go back up there later today did not seem too bad at that point in time, since we were still feeling pretty good.

after that, there's quite a steep descent down devil's corkscrew [5], followed by a shorter not-so-steep section. after that, we quickly got to the colorado river for the first time [6]. this is where it got a bit tougher, getting to phantom ranch was easy, but the way from there to cottonwood took as longer than expected, as it's all a slight uphill and it already getting a bit warm. cottonwood was the last place where we stopped together [7], two of our group were turning back from there, while three planned to go all the way to the north rim.

shortly after cottonwood (after the pumphouse residence) the trail starts climbing, and we walked most of the steeper part up to the supai tunnel and eventually to an overlook not too far from the north rim [8]. from this overlook, you can see most of the trail you've just climbed in this side canyon of a side canyon of the actual main canyon. from the overlook it's only another mile to the north rim trailhead, where we arrived just at noon, after 6:45 of travel time and about 5:00 of moving time (we had way too many stops along the way).

another group of runners who did the south-to-north run and finished at the north rim had a group of people waiting for them who had brought a nice selection of drinks for the finishers [9]. they were kind enough to offer us drinks, so we had nice cool drinks at our halfway point, before descending into the canyon again.

the second downhill was quite a bit tougher than the first one, but since we had been saving our legs on the uphill, we were able to run all of it, which saved us quite a bit of time. the part between supai tunnel and roaring springs is probably the prettiest and most spectacular part of the trail, first descending in the red supai rock, then crossing over to the other side [10], and then snaking along a pretty steep part of the canyon.

after getting down to the bottom of bright angel canyon, we realized that it was already pretty hot, and the plan was to get to phantom ranch as fast as possible. we packed some water at the pumphouse residence and then made the strategic mistake of not briefly stopping and refilling at cottonwood. the part from the residence to phantom ranch is about 9 miles, and we were tired, and it was hot. we moved very slowly and eventually ran out of water. luckily, we made it back to phantom ranch at 3.40, just before the cantina closed, and got a nice big lemonade.

the part from phantom ranch to the start of the climb, along the colorado river [11], showed us how tired we were already, and at that point the group fell apart fro good, with everybody going at their own pace to make it back up to the south rim. the climb up devil's corkscrew wasn't too bad, and the not-so-steep sections before and right after indian garden were the last opportunity to run a little.

from indian garden, the way back is nicely structured into 1.5 mile sections between the resthouses, so there always is something to get to that's not too far away. i tried to not stop at all, but eventually ran out of calories and had to stop for a final gel (had enough for quite a while) and some water between the rim and the first resthouse.

when i got to the rim, the sun was just setting, creating a very beautiful scenery for that last couple of switchbacks up [12]. i got to the trailhead at 7.45, after a total travel time of 14:25 and a total moving time of 10:48, very exhausted and very happy to be done [13]. this is definitely not something i'll be doing again anytime soon, but the feeling of accomplishment was pretty great, especially the next day sitting on the south rim, looking over to the north side, and thinking: we ran there yesterday. and back.

lessons for next time? not all that many. take better care of the feet, eat more calories, drink water at each and every water source, spend less time sitting around. if you're planning to do this, feel free to get in touch. some things to keep in mind: conserve energy, eat, drink, eat, drink, and take it easy on the downhills to make sure that the quads are still in working conditions after two major descents. if you're interested in the GPS track, it is available at garmin connect, but since quite a bit of the run is in very narrow canyons, the quality of the track is pretty bad in those parts. it's still fun to look at in google earth, though, in particular with 3d terrain. my GPS went completely crazy because of reception problem and reported 400 miles (600km) in the end, which probably is not quite accurate. from other reports it seems that the route we took is 47 miles (76km) long. after doing this, my idea of maybe doing a 100 mile race one day does not look all that appealing anymore...

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

and just in case you're looking for some other reports about running rim-to-rim-to-rim, here are some of the reports i found interesting and helpful to get an idea of how it's like:

• Grand Canyon Rim-to-Rim-to-Rim Run, Davy Crockett
• Grand Canyon Rim-to-Rim-to-Rim Route and How-To Information, Andrew Skurka
• The Canyon Challenge: Running Rim-to-Rim-to-Rim in the Grand Canyon, Meghan M. Hicks

5th International Workshop on Web APIs and Service Mashups (Mashups 2011): Call for Papers

5th International Workshop on Web APIs and Service Mashups (Mashups 2011)

Associated with ECOWS 2011

September 14, 2011, Lugano, Switzerland
Paper Submission Deadline: June 15, 2011

Objectives

Service computing and Web 2.0 are converging into a programmable as well as composable Web. This development provides the foundation for Service Mashups — compositions of Web APIs, Web content and Web data sources. The result is a novel class of diversified, agile and interactive software systems that provide rich user experience and allow new fields of application.

However, the integration of service computing and Web 2.0 technologies exposes various complexities like programming models and methodologies, service models that are well-suited for mashups, platforms and ergonomics in different operational contexts, as well as economic and social environments. Addressing some or all of these issues is an ongoing area of research and innovation, as new platforms for service delivery and service implementation constantly enter the marketplace.

The Mashups 2011 workshop solicits contributions addressing these issues and aims to bring together various relevant communities from academia and industry working on a) mashup-based applications, b) generic mashup tools, platforms and infrastructure, c) cross-cutting concerns of software service engineering and d) related topics from areas like social networking or economics.

Mashups 2011 continues the tradition of four previous events (2007 in Vienna, 2008 in Sydney, 2009 in Orlando, and 2010 in Cyprus) that not only offer a broad range of papers in this space, but also present keynote speakers from leading industry groups currently offering mashup tools and platforms.

Topics

Contributors are invited to submit original research papers addressing relevant aspects of mashup applications, technologies and engineering. Topics of interest include, but are not limited to, the following:

• Languages, frameworks, and platforms for the design, implementation, testing and maintenance of services mashups, including dynamic languages and frameworks.
• New approaches to mashup construction: data flow-, document-, spreadsheet- and process-oriented mashups, end-user mashup development, mashups in the cloud.
• Novel applications of mashups, e.g., mobile, location-aware or wiki-based.
• Specific service mashup application and technology examples with respect to design, architecture, implementation, usability and user-experience.
• Mashups within social software platforms, e.g., OpenSocial or Facebook.
• Mashups within and across enterprises.
• Quality of service and mashups: performance, reliability, security privacy or other non-functional aspects.
• Analysis of and experience with services mashups (creation, deployment, and usage) from social and economical perspectives; services markets and marketplaces, digital communities, pricing and contracting models.
• Experience reports on short-term and long-term maintenance and evolution of mashups.

Important Dates

• Submission Deadline: June 15, 2011
• Notification Due: July 15, 2011
• Final Version Due: August 12, 2011
• Workshop Date: September 14, 2011

Submission Instructions

Authors are invited to submit original, previously unpublished research papers. Two kinds of contributions are sought: short position papers (not to exceed 4 pages) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages) describing novel solutions to relevant problems. Papers need to comply to ACM format (http://www.acm.org/sigs/publications/proceedings-templates) and are to be submitted electronically in PDF format via EasyChair at http://www.easychair.org/conferences/?conf=mashups2011

All submissions will be peer-reviewed by members of the international program committee. Paper acceptance will be based on originality, significance, technical soundness, and clarity of presentation. Accepted papers will be included in the workshop proceedings, and circulated to participants prior to the event. Accepted workshop papers will be published as part of the ACM Digital Library (under negotiation).

At least one author of an accepted paper must register and participate in the workshop. Registration is subject to the terms, conditions and procedure of the main ECOWS conference to be found on their Web site at http://ecows2011.inf.usi.ch/

Organizing Committee

• Agnes Koschmider, Karlsruhe Institute of Technology, Germany
• Erik Wilde, University of California, Berkeley, USA
• Christian Zirpins, Karlsruhe Institute of Technology, Germany

If you have any questions, please contact the workshop chairs at mashups2011@easychair.org

 

Program Committee

• Victoria Torres, UP Valencia, Spain
• Willem-Jan van den Heuvel, University of Tilburg, Netherlands
• Eric Wohlstadter, UBC, Canada
• Rosa Alarcon, Catholic University of Chile, Chile
• Christoph Bussler, MercedSystems, USA
• Florian Daniel, University of Trento, Italy
• Schahram Dustdar, Vienna University of Technology, Austria
• George Feuerlicht, University of Technology Sydney, Australia
• Martin Gaedke, Chemnitz University of Technology, Germany
• Mehdi Jazayeri, University of Lugano, Switzerland
• Gerti Kappel , TU Vienna, Austria
• Rania Khalaf, IBM Watson Research Center, USA
• Marek Kowalkiewicz, SAP, Australia
• Peep Küngas, University of Estonia, Estonias
• Maristella Matera, Politecnico di Milano, Italy
• Michael Maximilien, IBM Almaden Research Lab, USA
• Cesare Pautasso, USI Lugano, Switzerland
• Ajith Ranabahu, Apache Foundation, USA
• Nelly Schuster, FZI Forschungszentrum Informatik, Germany
• Stefan Tai, Karlsruhe Institute of Technology, Germany
• Michiaki Tatsubori, IBM Research Tokyo, Japan

Previous Editions

• Mashups 2010: http://mashup.inf.unisi.ch/mashups2010/
• Mashups 2009: http://www.mashup-oopsla.org/
• Mashups 2008: http://sites.google.com/a/icsoc-mashups.org/mashups-08-icsoc/
• Mashups 2007: http://sites.google.com/a/icsoc-mashups.org/mashups-08-icsoc/Mashups-07