The navigation structure of Web sites can be regarded as metadata that can be used for interesting applications in User Interface (UI) design and Human-Computer Interaction (HCI), as well as for Information Retrieval (IR) tasks. However, there currently is no established format for site metadata, which makes it hard for Web sites to publish their structure in a machine-readable way, which could then be used by HCI and/or IR applications. We propose a model and a format for site metadata that is built on top of an existing format and thus could be deployed with little overhead by publishers as well as consumers. Making site metadata available as machine-readable data can be used for improving user interfaces (informing user agents about the context of the page they are displaying) and better information retrieval (allowing search engines to use sitemap information for better ranking and display of the results).

Over the past few years, the discussion between the two major architectural styles for designing and implementing Web services, the RPC-oriented approach and the resource-oriented approach, has been mainly held outside of traditional research communities. Mailing lists, forums and developer communities have seen long and fascinating debates around the assumptions, strengths, and weaknesses of these two approaches. The Representational State Transfer (REST) is an architectural style and as such can be applied in different ways, extended by additional constraints, or specialized with specific interaction patterns. The Third International Workshop on RESTful Design (WS-REST 2012) aims to involve researchers in the debate by providing a premier forum for discussing research ideas, novel applications and results centered around the resource-oriented style of Web services. The WWW conference provides the ideal setting to host this third edition of the workshop dedicated to research on the architectural style underlying the Web.

Representational State Transfer (REST) as an architectural style for service design has seen substantial uptake in the past years. However, some areas such as Business Process Modeling (BPM) and push services so far have not been addressed in the context of REST principles. In this work, we look at how both BPM and push can be combined so that business processes can be modeled and observed in a RESTful way. Based on this approach, clients can subscribe to be notified when certain states in a business process are reached. Our goal is to design an architecture that brings REST's claims of loose coupling and good scalability to the area of BPM, and still allow process-driven composition and interaction between resources to be modeled.

Representational State Transfer (REST) services are gaining momentum as a lightweight approach for the provision of services on the Web. Unlike WSDL-based services, in REST the set of operations is reduced, standardized, with well known semantics, and changes the resource's state. Few attempts have been proposed to support composition models for REST, they are mainly operation-centric and fail to acknowledge the hypermedia nature of REST, that is, clients must inspect the served resource state and choose the link to follow from there. We explore RESTful service composition as it is driven by the hypermedia net that is dynamically created while a client interacts with a server resulting in a light-weight approach. We based our proposal on a hypermedia-centric REST service description, the Resource Linking Language (ReLL) and Petri Nets as a mechanism for describing the machine-client navigation.

Users now interact with multiple Location-Based Services (LBS) through a myriad set of location-aware devices and interfaces. However, current LBS tend to be centralized silos with ad-hoc APIs, which limits potential for information sharing and reuse. Further, LBS subscriptions and user experiences are not easily portable across devices. We propose a general architecture for providing open and decentralized access to LBS, based on Tiled Feeds - a RESTful protocol for access and interactions with LBS using feeds, and Feed Subscription Management (FSM) - a generalized feed-based service management protocol. We describe two client designs, and demonstrate how they enable standardized access to LBS services, promote information sharing and mashup creation, and offer service management across various types of location-enabled devices.

In this demonstration-paper we present Mr. DLib, a machinereadable digital library.Mr. DLib provides access to several millions of articles in full-text and their metadata in XML and JSON format via a RESTful Web Service.In addition, Mr. DLib provides related documents for given academic articles.The service is intended to serve researchers who need bibliographic data and full-text of scholarly literature for their analyses (e.g.impact and trend analysis); providers of academic services who need additional information to enhance their own services (e.g.literature recommendations); and providers who want to build their own services based on data from Mr. DLib.

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 disruptive class of diversified, agile and interactive software systems that provide unprecedented 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).

This volume provides an overview and an understanding of REST (Representational State Transfer). Discussing the constraints of REST the book focuses on REST as a type of web architectural style. The focus is on applying REST beyond Web applications (i.e., in enterprise environments), and in reusing established and well-understood design patterns when doing so. The reader will be able to understand how RESTful systems can be designed and deployed, and what the results are in terms of benefits and challenges encountered in the process. Since REST is relatively new as an approach for designing Web Services, the more advanced part of the book collects a number of challenges to some of the assumptions and constraints of REST, and looks at current research work on how REST can be extended and applied to scenarios that often are considered not to be a good match for REST. This work will help readers to reach a deeper understanding of REST on a practical as well as on an advanced level.

Recent technology trends in Web services indicate that a solution eliminating the perceived complexity of the WS-* standard technology stack may be in sight: advocates of Representational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to radically simplify the plumbing required to implement a Service-Oriented Architecture (SOA). In this tutorial we give an introduction to the REST architectural style as the foundation for RESTful Web services. The tutorial starts from the basic design principles of REST and how they are applied to service oriented computing. Service-orientation concentrates on identifying self-contained units of functionality, which should then be exposed as easily reusable and repurposable services. This tutorial focuses not on the identification of those units, but on how to design the services representing them. We explain how decisions on the SOA level already shape the architectural style that will be used for the eventual IT architecture, and how the SOA process itself has to be controlled to yield services which can then be implemented RESTfully. We do not claim that REST is the only architectural style that can be used for SOA design, but we do argue that it does have distinct advantages for loosely coupled services and massive scale, and that any SOA approach already has to be specifically RESTful on the business level to yield meaningful input for IT architecture design.

Service descriptions allow designers to document, understand, and use services, creating new useful and complex services with aggregated business value. Unlike RPC-based services, REST characteristics require a different approach to service description. We present the Resource Linking Language (ReLL) that introduces the concepts of media types, resource types, and link types as first class citizens for a service description. A proof of concept, a crawler called RESTler that crawls RESTful services based on ReLL descriptions, is also presented.

Over the past few years, the discussion between the two major architectural styles for designing and implementing Web services, the RPC-oriented approach and the resource-oriented approach, has been mainly held outside of traditional research communities. Mailing lists, forums and developer communities have seen long and fascinating debates around the assumptions, strengths, and weaknesses of these two approaches. The Second International Workshop on RESTful Design (WS-REST 2011) has the goal of getting more researchers involved in the debate by providing a forum where discussions around the resource-oriented style of Web services design take place. Representational State Transfer (REST) is an architectural style and as such can be applied in different ways, can be extended by additional constraints, or can be specialized with more specific interaction patterns. WS-REST is the premier forum for discussing research ideas, novel applications and results centered around REST at the World Wide Web conference, which provides a great setting to host this second edition of the workshop dedicated to research on the architectural style underlying the Web.

Relational databases hold a vast quantity of information and making them accessible to the web is an big challenge. There is a need to make these databases accessible with as little difficulty as possible, opening them up to the power and serendipity of the Web. Our work presents a series of patterns that bridge the relational database model with the architecture of the Web along with an implementation of some of them. The aim is for relational databases to be made accessible with no intermediate steps and no extra metadata required. This approach can vastly increase the data available on the web, therefore making the Web itself all the more powerful, while enabling its users to seamlessly perform tasks that previously required bridging multiple domains and paradigms or were not possible.

This article introduces and discusses the concept of academic search engine optimization (ASEO). Based on three recently conducted studies, guidelines are provided on how to optimize scholarly literature for academic search engines in general, and for Google Scholar in particular. In addition, we briefly discuss the risk of researchers' illegitimately 'over-optimizing' their articles.

Schedule 1 Presenters Cesare Pautasso Erik Wilde 2 *OA Overload SOA and REST What is SOA? From SOA to REST What are Web Services? Resource Oriented Architecture (ROA) Web Oriented Architecture (WOA) Syndication Oriented Architecture (SynOA) Event Oriented Architecture (EOA) Conclusions Schedule Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 2 of 16 7/4/2010 19:54 Cesare Pautasso: Introduction This introduction presents the schedule, the tutorial presenters, and some background for the tutorial. Specifically, we briefly mention all the *OA terms that have been invented in recent years, such as SOA (Services), ROA (Resources), WOA (Web), SynOA (Syndication), and EOA (Event), and set them into context. Our main goal is to explain our notion of SOA for the purpose of this tutorial, and what we perceive as the core tasks when moving from SOA to REST. Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 3 of 16 7/4/2010 19:54 Cesare Pautasso: Introduction 9.00-10.30: Intro & What is REST? [What is REST?] 11.00-12.30: RESTful Service Design [RESTful Service Design] 14.00-15.30: REST vs. WS-* Comparison [REST vs. WS-* Comparison] 16.00-17.30: REST in Practice [REST in Practice] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 4 of 16 7/4/2010 19:54 Computer Science at Politecnico di Milano, Italy [http://www.polimi.it] Ph.D. at ETH Zürich [http://www.ethz.ch/index_EN] (2004) Post-Doc at ETH Zürich [http://www.iks.inf.ethz.ch/] Software: JOpera: Process Support for more than Web services [http://www.jopera.org] Researcher at IBM Zurich Research Lab [http://www.zurich.ibm.com] (2007) Assistant Professor at the Faculty of Informatics [http://www.inf.unisi.ch/] (since September 2007) Representations: Web [http://www.pautasso.info]; twitter [http://twitter.com/pautasso] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 5 of 16 7/4/2010 19:54 Presenters Cesare Pautasso: Introduction Computer Science at Technical University of Berlin (TUB) [http://www.tu-berlin.de /eng/] (1988-1991) Ph.D. at ETH Zürich [http://www.ethz.ch/index_EN] (1992-1997) Post-Doc at ICSI, Berkeley [http://www.icsi.berkeley.edu/] (1997/98) book on “Technical Foundations of the World Wide Web [http://dret.net/netdret/publications#wil98]” Various activities back in Switzerland (1998-2006) teaching at ETH Zürich [http://www.ethz.ch/index_EN] and FHNW [http://www.fhnw.ch/] working as independent consultant research focus on Web architecture and XML technologies Professor at the School of Information [http://ischool.berkeley.edu/] (since Fall 2006) technical director of the Information and Service Design (ISD) program [http://isd.ischool.berkeley.edu/] Representations: Web [http://dret.net/netdret/]; blog [http://dret.typepad.com/]; twitter [http://twitter.com/dret] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 6 of 16 7/4/2010 19:54 Service-Oriented Architecture (SOA) Service: How to define a service Architecture: How to apply SOA in the design/implementation process Representational State Transfer (REST) Representation: Resources (not functions) are the primary abstraction State: Trying to push state to the “edges” (client or resource) Transfer: Focus on the exchange of representations (uniform interface) Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 7 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction What is Service-Oriented Architecture? Alignment of business objectives and IT can be implemented with any architecture, technology, product SOA explained like this is more for business-oriented people this definition is not within the realm of technical terms 1. Technical architecture (interfaces are exposing services) focus on IT and the idea of services as the main abstraction still little guidance on how exactly a service is identified and exposed this definition is in the right space, but often highly underspecified 2. SOA as the high-level explanation for WS-* Web Services [http://en.wikipedia.org/wiki/Web_service] this is how SOA as a buzzword started (“SOA as architecture for Web Services”) most SOA products are focusing on this (rather narrow) view of Web Services this definition has many implicit decisions built-in 3. Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 8 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction Starting from the second definition of SOA a technical architecture for structuring/implementing a service landscape many crucial aspects are undefined/underspecified and need clarification Services can come in a variety of flavors IT services often are guided by middleware/RPC views of the world Web architecture does not expose middleware/RPC views of services Web services (not the WS-* kind) are exposed as resources and links aligning Services and the Web means redefining services From SOA to REST is about SOA and Web architecture SOA with the goal of designing services for the Web the most important part is to get the “service” part right RESTful SOA means properly designing/implementing Web services Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 9 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. “Web Services Architecture”, W3C Working Group Note, February 11, 2004 [http://www.w3.org/TR/ws-arch/#whatis] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 10 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction More concrete guidelines for Web-based implementations Taking services and turning them into RESTful Web services Query string parameters are appropriate if they are inputs to a Resource which is an algorithm Prefer pragmatic uses of putting data into URI, instead of using HTTP Headers RPC-style APIs are avoided in favor of Resources and protocols A representation of a resource should have many links to the other resources in the application, so that a client can discover state transitions URI templates provide the technology behind specifying families of URI to clients Not really an architecture, more a “set of engineering principles” Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 11 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction “WOA: Putting the Web back in Web Services” Unclear distinction from ROA (maybe no HTTP extensions?) Questionable conceptual landscape “REST is the protocol most preferred since it's a natural extension of HTTP for the purposes of sharing self-describing information and state.” [http://hinchcliffe.org/archive/2006/08/05/8489.aspx] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 12 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction Syndication can be regarded as a pattern for information dissemination Atom [REST in Practice; Atom (1)] and Atom Publishing Protocol (AtomPub) [REST in Practice; Atom Publishing Protocol (AtomPub) (1)] are existing Web standards for syndication SynOA is a pattern for building a SOA architecture services are defined around collections interactions are centered around reading and updating feeds Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 13 of 16 7/4/2010 19:54 *OA Overload Cesare Pautasso: Introduction Riding the SOA wave for event-oriented systems Now trademarked by eClient [http://www.eclient.com/] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 14 of 16 7/4/2010 19:54 Cesare Pautasso: Introduction *OA is hard to define and very hype-sensitive SOA lacks well-defined ways of how to define a service Business-level SOA tends to be implemented RPC-oriented/WS-* RESTful SOA is a better route for achieving loose coupling [http://dret.net/netdret/docs/loosely-coupled-www2009/] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 15 of 16 7/4/2010 19:54 Cesare Pautasso: Introduction 9.00-10.30: Intro & What is REST? [What is REST?] 11.00-12.30: RESTful Service Design [RESTful Service Design] 14.00-15.30: REST vs. WS-* Comparison [REST vs. WS-* Comparison] 16.00-17.30: REST in Practice [REST in Practice] Abstract (2) http://localhost/repositories/drectures/rest-icwe2010/intro 16 of 16 7/4/2010 19:54

One of the main goals of the Recovery.gov Web site is to provide information about how funds for the American Recovery and Reinvestment Act (ARRA) of 2009 are allocated and spent. In this report, we propose a reporting architecture that would focus on the reporting services rather than the Web site and page design, and that uses these Web services to build the user-facing part of ARRA reporting. Our proposed architecture is based on simple and well-established Web technologies, and the main goal of this architecture is to provide citizens and watchdog groups simple and easy access to machine-readable data. Our architecture uses a more sophisticated framework than simple downloads of data files. Our proposed architecture is based on the principles of Representational State Transfer (REST) and uses established and widely supported Web technologies such as feeds and XML. We argue that such an architecture is easy to design and implement, easy to understand for users, and easy to work with for those who want to access ARRA reporting data in a machine-readable way.

Managing information, access to information, and updates to relevant information on the Web has become a challenging task because of the volume and the variety of information sources and services available on the Web. This problem will only grow because of the increasing number of potential information resources, and the increasing number of services which could be driven by machine-friendly access to these resources. In this paper, we propose to use the established and simple metamodel of feeds as a proxy for information resources on the Web, and to use feed-based methods for producing, aggregating, querying, and publishing information about resources on the Web. We propose an architecture that is flexible and scalable and uses well-established RESTful methods of loose coupling. By using such an architecture, mashups and the repurposing of Web services is encouraged, and the simplicity of the underlying metamodel places no undue restrictions on the possible application areas.

Loose coupling is often quoted as a desirable property of systems architectures. One of the main goals of building systems using Web technologies is to achieve loose coupling. However, given the lack of a widely accepted definition of this term, it becomes hard to use coupling as a criterion to evaluate alternative Web technology choices, as all options may exhibit, and claim to provide, some kind of "loose" coupling effects. This paper presents a systematic study of the degree of coupling found in service-oriented systems based on a multi-faceted approach. Thanks to the metric introduced in this paper, coupling is no longer a one-dimensional concept with loose coupling found somewhere in between tight coupling and no coupling. The paper shows how the metric can be applied to real-world examples in order to support and improve the design process of service-oriented systems.

Location-based services are becoming increasingly Web-based, as a result of the availability of networked mobile devices and mobile Internet access. The "Location and the Web (LocWeb)" workshop targets the capabilities and constraints of Web-based location-based services, which can be implemented as browser-based applications, or as native applications using Web services. The focus of this CHI workshop is on approaches which handle the complexity of location-based services, specifically looking at location abstractions, location sharing, context-relevant information, privacy issues, and interface and interaction design. The goal of this workshop is to serve as a starting point for attaining a better understanding of how the Web has to change in order to embrace location as a first-level concept, and how these changes might be reflected in applications and user interfaces that transform the Web into a platform for location-based services.