Resource-Orientation and Service-Offering Systems

fishhookFladgeInternet and Web Development

Dec 13, 2013 (3 years and 6 months ago)

94 views

Resource
-
Orientation and
Service
-
Offering Systems

Michael
Athanasopoulos

PhD student, School of ECE,

National Technical University of Athens

athanm@softlab.ntua.gr

2nd Workshop on

Leveraging REST in Enterprise Service Systems

CASCON 2011

Overview


The REST trend



Resource
-
orientation and offering services



REST
-
inspired SOA



Challenges and issues for enterprise systems



THE REST TREND

Introduction

REST APIs on the Web

REST

60%

SOAP

25%

JavaScript

7%

XML
-
RPC

5%

Other

3%

APIs by access protocol, 2008

REST

72%

SOAP

16%

JavaScript

6%

XML
-
RPC

3%

Other

3%

APIs by access protocol, 2011

Source: ProgrammableWeb.com

Research on REST

Based on search results from Google Scholar, October 2011

Books on REST

May 2007

Nov 2008

Nov 2009

Nov 2009

Feb 2010

Sep 2010

Aug 2011

expected Dec 2011

2000

Frameworks for
RESTful

services


.NET Open
-
Source:
OpenRasta
,
ServiceStack
,
RestSharp


ColdFusion: ColdFusion on Wheels, Mach
-
II, Taffy


Ext JS


Grails JSON
-
REST
-
API
plugin


Java
Jt

Design Pattern Framework, Wink,
Restlet
,
JBoss

RESTEasy
, Jersey, Apache CXF,
NetKernel
,
Apache Sling,
Restfulie
, Play Framework, Spring Framework, Mule


Microsoft's WCF Data Services, WCF Web
Api


Microsoft's ASP.NET MVC


Perl Catalyst, Dancer,
Mojolicious


PHP
DooPHP
,
Symfony
,
Zend

Framework,
CakePHP
,
Kohana
, Sapphire, FRAPI, RECESS, Simple
-
REST


Python
Tastypie
,
django
-
piston,
django
-
rest
-
framework,
django
-
rest
-
interface
django
-
restapi
,
web.py,
lazr.restful


Ruby on Rails, Sinatra,
Restfulie


TurboGears2 provides a
RestController


ZEST
-

lightweight Struts
-
like Web framework


ERRest

-

REST framework for Apple's WebObjects


Source: Wikipedia.org,
http://en.wikipedia.org/wiki/Representational_state_transfer#Framework_implementations

RESOURCE
-
ORIENTATION AND
OFFERING SERVICES

RESTful

Web services

What is REST

An architectural style…


a specialization of element and relation types, and


a set of coordinated constraints that restrict the elements’
and relations’ roles and features


…for distributed network
-
based application
software.


Example & inspiration: the WWW.


Proposed in Roy T. Fielding’s dissertation in 2000.

Why REST


Because of the Web (which is based on REST
principles).



Fielding argues that: “REST emphasizes


scalability of component interactions
,


generality of interfaces
,


independent deployment of components
, and


intermediary components to reduce interaction
latency
, enforce
security
, and
encapsulate legacy
systems
.”

REST elements and constraints


Element types:


Data
: resource, resource identifier, resource representation,
resource metadata, control data


Components
: user agent, origin server, proxy, gateway


Connectors
: client, server, cache, resolver, tunnel



Constraints:


Client
-
Server


Stateless (communication)


Cache


Uniform interface


Layered System


Code
-
On
-
Demand (optional)

Resource
-
Oriented Architecture


Term coined
RESTful

Web services book, chapter 4 (2007)



In a sentence: Using REST principles and Web’s standards for building
service offering systems.



Parts:


Resources


Resource names


Resource representations


Links between resources



Properties:


Addressability


Statelessness


Connectedness

Resource
-
oriented design: rationale


Resource
-
Oriented Architecture (ROA)

has been proposed as an
alternative paradigm for designing service
-
offering systems and
applications through the Web.



RESTful

Web services

realize ROAs and utilize Web’s well
established and widely adopted principles, protocols and
standards (e.g. HTTP, URI, IANA’s repository for media types and
link relations, etc.).



REST
-
inspired architectural designs

may be utilized to yield SOAs
that demonstrate improvements with respect to certain significant
properties such as:


scalability, simplicity,
evolvability
, extensibility, reusability, visibility,
portability, reliability

Resource
-
Oriented services


The basic form of functionality decomposition
is the concept of a
resource
.



Resources:


capture semantics


have state and carry information


have structure that is not visible to clients


have relationships with other resources


may be manipulated by clients (and servers)

RESTful

Web services


URIs identify resources.



HTTP control data and metadata are used to convey information
related to the purpose of the interaction.


HTTP methods (GET, PUT, POST, DELETE and maybe others) are used to
retrieve and manipulate the resources.


HTTP metadata and response codes are used to indicate aspects of the
interaction.



Representations are used to convey the informational content of
resources.



Links, forms and “hypermedia elements” in general are used to
connect resources together and offer future state transitions.

The REST triangle

Resource identifiers are
defined using URI spec.

HTTP
methods

Standard or
custom media
types

“REST triangle” term coined by Benjamin Carlyle, http://soundadvice.id.au/blog/EnterpriseREST.html



Link relations



Hypermedia

Nouns

(Resources)

e.g. http://.../orders/1234

Verbs

e.g. GET

Representations

e.g. application/
atom+xml



(and representation metadata)

UNCONSTRAINED

CONSTRAINED

CONSTRAINED

Media types in REST


By definition, resource representations include both data
and (representation) metadata.



Media types are used to:


prescribe formats for the data that are exchanged, and


provide a processing model for the application or resource



Fielding mentions*:

A REST API should spend almost all of
its descriptive effort in defining the media type(s)

used for
representing resources and driving application state, or in
defining extended relation names and/or hypertext
-
enabled
mark
-
up for existing standard media types.”

*”

REST APIs must be hypertext
-
driven”, Roy Fielding,
http://roy.gbiv.com/untangled/2008/rest
-
apis
-
must
-
be
-
hypertext
-
driven

Link relations


Attributes attached to hyperlinks to define the link’s type.



IANA’s maintains a repository* of Link relations include 53
link relations.



RFC 5988 includes a description of a process for registering
relation types and a specification for link headers.



Examples:


<link
rel
="
stylesheet
"
href
="example.css"/> (HTML)


Link: <http://example.com/TheBook/chapter2>;
rel
="previous";
title="previous chapter“ (Link header)

*Links Relations repository, http://www.iana.org/assignments/link
-
relations/link
-
relations.xml

Hypermedia


Fielding states*:

When I say
Hypertext, I mean
the simultaneous
presentation of information and
controls such that the information
becomes the affordance through
which the user obtains choices and
selects actions.




Both data and metadata may be used
for providing choices.



Responses should contain all the
required information for a client to
choose and be able to transit to a
new state. Hypermedia technologies
include:


Links (e.g. URIs in responses)


Forms (e.g. HTML / XHTML forms,
XForms
, URI Templates,
OpenSearch
)


H factor**:
a measurement of the
level of hypermedia support and
sophistication of a media
-
type.


Link Support


[LE] Embedding links


[LO] Outbound links


[LT]
Templated

queries


[LN] Non
-
Idempotent updates


[LI] Idempotent updates

Control Data Support


[CR] Control data for read requests


[CU] Control data for update requests


[CM] Control data for interface methods


[CL] Control data for links

*“A little REST and Relaxation”, Roy Fielding, http://www.slideshare.net/royfielding/a
-
little
-
rest
-
and
-
relaxation

**Hypermedia Types, Mike Amundsen, http://amundsen.com/hypermedia/hfactor

REST
-
based Web services: maturity

Adapted from Richardson Maturity Model, for more information visit: http://www.crummy.com/writing/speaking/2008
-
QCon/act3.html

Bookstore example

media type

application/
vnd.ntua.b
ookstore.order+xml

media type

application/
vnd.ntua.book
store.orderitem+xml

link relation

item

hypermedia

URI + relation

verb

GET

noun

orders

REST
-
INSPIRED
SOA


Design enterprise systems in a
RESTful

way

REST
-
inspired SOA Design Patterns


Reusable Contract


Lightweight Endpoint


Content Negotiation


Entity Linking


Response Caching


Content Distribution
Network


Endpoint Redirection


Decoupled Validation
Logic


Code
-
On
-
Demand


Deferred Controller


Idempotent Capability


Resource Crawling


Hyperlinked Contracts

Source: http://www.soapatterns.org, more information: Book SOA with REST (expected in December 2011)

REST
-
inspired SOA Design Patterns


Reusable Contract
:
Expose the service capabilities via a common, reusable
technical service contract that provides a set of abstract, multi
-
purpose
methods that allow service
-
specific capability logic to be chosen at
runtime.



Lightweight Endpoint
:
Expose data and functionality associated with
business entities as a series of granular, lightweight endpoints.



Entity Linking
:
Services inform their consumers about the existence of
related entities as part of the consumer's interactions with the services.



Content Negotiation
:
Allow alternative representations of the data to be
returned by the same service capability, and use metadata in each request
message to select the most appropriate representation for the
corresponding response message.

CHALLENGES AND ISSUES FOR
ENTERPRISE SYSTEMS


REST in the Enterprise

Formal service description


Several schools of thought in the REST community.


Should be avoided due to the coupling it introduces.


Not required, but useful for documenting service capabilities
and promoting common understanding.


Should be provided as contract
-
like reference (which would also
allow stub code generation).



Main arguments:


the
communication protocol
, the
universal naming mechanism

and the
media types

used, along with a set of entry
-
point
resource identifiers (“
bookmarks
”) should be enough for
accessing and traversing service capabilities.


semantics of interactions

with the server may be provided
through
human
-
readable documentation
.

Formal service description


In practice most Web APIs provide:


Templates and guidelines of how to craft URIs at
development time.


Human
-
readable descriptions for describing the
semantics of what URIs identify and what interactions
mean for the application.


JSON and XML are used to represent data.


HTTP methods and other conventions (e.g. which
metadata or which response codes are used) are also
provided through human readable documentation.


A few APIs also provide WADL specifications.

Beyond
-
CRUD operation semantics


Notes:


Using HTTP verbs for CRUD is
just

a convention that does not violate
their semantics.


Using HTTP protocol is also
just

a selection of communication protocol.



General approach: when you cannot extend the fixed set of actions,
the set of resources and their relationships.



However several other patterns are proposed:


Decomposition of complex operations to CRUD
-
like interactions.


Side
-
effect free calculations: results as query
-
responding resources.


Transaction resources for operations modifying more than one visible
resources at once.


More issues


Distributed transactions


Transaction managers | Specification efforts (REST
-
*) | Protocols (RETRO)



Asynchronous interactions


202 Accepted + Feedback URI | 201 Created + Result Location URI



Publish/subscribe support


Syndication & polling for changes (Real
-
time applications?)



Reliability mechanisms


Application re
-
design problem | POST Once Exactly (Mark Nottingham) | SOA
-
Reliability (
Yaron

Goland
) | HTTPLR (Bill de
hOra
)



Tooling support and developer productivity

Conclusions


REST and resource
-
orientation
attracts significant attention

as an
alternative paradigm for offering services through the Web.



RESTful

Web services are based on Web
widely adopted and supported
standards and protocols
and can be used to implement ROAs.



REST and Web architecture principles help evolve
patterns

used for
designing SOAs in order to induce certain
desired properties

to
implementations.



Several issues and challenges are still open but more and more people
welcome REST in the Enterprise.



The co
-
existence of traditional and resource
-
oriented service
-
offering
components itself places one of the most interesting challenges: their
functional and technological integration
.

References


Fielding, Roy Thomas.
Architectural Styles and the Design of Network
-
based Software Architectures
. Doctoral dissertation, University of
California, Irvine, 2000.


URI: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm


Roy Fielding’s presentation at
ApacheCon

(2008)


URI: http://roy.gbiv.com/talks/200804_REST_ApacheCon.pdf


RESTful

Web services book (2007)


URI: http://oreilly.com/catalog/9780596529260


REST in Practice book (2010)


URI: http://restinpractice.com/


REST: From Research to Practice (2011), Springer


URI: http://www.springer.com/engineering/signals/book/978
-
1
-
4419
-
8302
-
2


“Addressing Doubts about REST” by Stefan
Tilkov
,


URI: http://www.infoq.com/articles/tilkov
-
rest
-
doubts


Thank you!

Michael
Athanasopoulos
,

PhD student, NTUA

athanm@softlab.ntua.gr

2nd Workshop on

Leveraging REST in Enterprise Service Systems

CASCON 2011