-overview of res tful architecture-2

1. overview of RESTful Architecture
Jun-Hawn Huh
ijhhuh@mobile.re.kr
Mobile Networking and Computing Lab.
Dept. of Electronics, Electrical and Computer Science and Engineering
1

2. INDEX
2
1 Introduction
2
3
4
5
REST : design strategy
REST : set of constraints
REST : guidelines for REST interface
Your API is “fully RESTful”?
6 Conclusion
Representational State Transfer ( REST )

3. Introduction : Architecture
Architecture
an abstraction of the run-time elements
of a software systems during some phase
of its operation. A system may be
composed of many levels of abstraction
and many phases of operation, each with
its own software architecture.
defined by a configuration of architectural
elements—components, connectors, and
data—constrained in their relationships
in order to achieve a desired set of
architectural properties.
3
Abstraction
: hiding some of the details of a system
through encapsulation in order to better
identify and sustain its properties
Elements
Component
: A component is an abstract unit of software
instructions and internal state that provides a
transformation of data via its interface.
Connectors
: A connector is an abstract mechanism that
mediates communication, coordination, or
cooperation among components.
Data
: A datum is an element of information that is
transferred from a component, or received by
a component, via a connector.

4. Introduction : Design Pattern
Design Pattern
A design pattern is a set of guidelines
4
Protocol
A protocol is pattern you need to fit exactly VS
Example) House Design
roof
width : 15m
height : 3m
shape : triangle
material : oak tree
doorpull
radius: 15cm
shape : circle
material : stainless
door
width : 1m
height : 2m
shape : rectangle
material : cherry tree
house pattern
< korean-style house >
< adobe-style house >
< carftsman-style house>
Strict non-strict

5. Introduction : Hyper -
Hypertext
Hypertext is text displayed on a computer display or other electronic
devices with references (hyperlinks) to other text which the reader can
immediately access, or where text can be revealed progressively at multiple
levels of detail
5
Hyper -
The English prefix hyper- comes from the Greek prefix "ὑπερ-" and means "over" or “beyond"
h y p e r
Hypermedia
Hypermedia, an extension of the term hypertext, is a nonlinear medium
of information which includes graphics, audio, video, plain text and
hyperlinks. This contrasts with the broader term multimedia, which may
include non-interactive linear presentations as well as hypermedia.
Ted-Nelson
- by Ted Nelson

6. Introduction : Hyper -
6
Hyper Card ( developed by apple )
- HyperCard was originally released in 1987 for $49.95
- First GUI-Browser Mosaic was release in 1993
Find the API using Hypermedia in Hyper Card
- Click the button : call API
- Operations after click the button : sound play, video play, take you to a different card : Hypermedia
- “cards” with links that performed different function
- clicking on link might play a sound, video, take you to a
different card

7. Introduction : REST
7
Representational State Transfer ( REST )
Roy T Fielding- The term “REST” was coined back in 2000 by Roy T Fielding
- Reference Paper : Architectural styles and the design of network-based software architectures
- Software architecture style of the World Wide Web
Why call REST ( Representational State Transfer )?
- Representational : resource is represented by type( XML, JSON, anytype )
- State Transfer: Transmit resource’s state
Roy T Fielding
- Roy Thomas Fieding( born 1965 ), american, computer scientist
- one of the principal author of the HTTP spec
- Transffering Representational State
REST’s goal ?
- Scalability of component interactions
- Genrality of interfaces
- Independent deployment of components

8. REST : design strategy
8
Two approach to design architecture
1) starting with the nothing
2) start with the system need as a whole
example ) - Draw a Wheel
1) 2)
null
creative ! natural !

9. 9
REST : design strategy
null style
put in here, set of constraints
server - client
stateless
cacheable
layered system
code on demand ( optional )
uniform interface
natural !
constraint for REST interface
identification of resources
Manipulation of resources
through these representations
self-descriptive message
Hypermedia as the engine of
application state
< Hybrid Style >

10. REST : set of constraints
10
client - Server
Stateless
A uniform interface separates client from servers.
The client–server communication is further constrained
by no client context being stored on the server between
requests
client server
request
response
interface
independent
client server
request
response
I don’t know
who is client !
I don’t care about
who is client !
also,

11. REST : set of constraints
11
cacheable
Well-managed caching partially or completely eliminates some client–server
interactions, further improving scalability and performance.
layered system
code on demand ( optional )
uniform interface ( important )
A client cannot ordinarily tell whether it is connected directly to the end server, or to
an intermediary along the way.
Servers can temporarily extend
or customize the functionality of
a client by the transfer of
executable code.
The uniform interface simplifies
and decouples the architecture,
which enables each part to
evolve independently.
< Process View of a REST-based Architecture >

12. REST : set of constraints
12
client server
call getWeather( “Busan” )
client server
Get ( “/weather/busan" )
RPC ( Remote Procedure Call )
REST
return “Sunny”
callgetWeather()
functionlocally
return “Sunny”
weather
busan
sunny
seoul
rainy
return
representationalstate

13. REST : constraint for REST interface
13
Identifiaction of resources
Manipulation of resources through these representations
Individual resources are identified in requests, for example using URIs in web-
based REST systems. The resources themselves are conceptually separate
from the representations that are returned to the client.
When a client holds a representation of a resource, including any metadata
attached, it has enough information to modify or delete the resource.
XML, JSON, vnd.onem2m-res+xml, vnd.onem2m-res+json …

14. REST : constraint for REST interface
14
self-descriptive message
Each message includes enough information to describe how to process
the message
client server
request
response
self-descriptive message
contents
Idon’tw
anna
seeyou(contents)
but,Iknow
you
already
headers

15. REST : constraint for REST interface
15
Hypermedia As The Engine Of Application State ( HATEOAS )
{
“id” : “1”
“subject” : “Hello World!”
“created” : “2015-01-01T12:00:00.000”
“author” : “junhwan”
}
{
“id” : “1”
“subject” : “Hello World!”
“created” : “2015-01-01T12:00:00.000”
“author” : “junhwan”
“comments-href” : “/book/1/comments”,
“profile-href” : “/profiles/junhwan”
“recommend-href” : /book/1/recommend”
}
{
“id” : “1”
“subject” : “Hello World!”
“created” : “2015-01-01T12:00:00.000”
“author” : “junhwan”
“links” : [
{
“href” : “/book/1”
“rel” : “self”
}, {
“href” : “/book/1/comments””
“rel” : “comments”
}, {
“href” : “/profiles/junhwan
“rel” : “profile”
}, {
“href” : “/book/1/recommend”
“rel” : “recommend”
},
}
close
to
hyperm
edia
API

16. REST : Your API is “fully RESTful”?
16
The Richardson Maturity Model
level 0
level 1
level 2
level 3
closeto“fullyRESTful”
one URI
Indivisual URIs for each resource
Uses the right HTTP method, status codes
Response have links that the clients can use ( HATEOAS )
- SOAP, XML RPC, POX
- Single URI
- URI design
- Many URIs, Single operation
- Many URIs, many operation
- CRUD services
- Level2 + Hypermedia
- RESTful Services

17. Conclusion
17
- study REST’s set of constraints
- study meaning of “fully RESTful”
Future
- implement “fully RESTful” system
- HATEOAS
- codeOnDemand
- …
Question
- How authentication in RESTful web service ?
- using HTTP is the best for RESTful?

18. Thank you
18

19. Reference
19
[1] Fielding, Roy Thomas. Architectural styles and the design of network-based software
architectures. Diss. University of California, Irvine, 2000.
[2] https://www.youtube.com/watch?v=qHbTE3qvUsQ , online lecture about REST, koushik
[3] http://blogs.mulesoft.com/dev/api-dev/api-best-practices-hypermedia-part-1/ , Mike Stowe
[4] Barish, Greg, and Katia Obraczke. "World wide web caching: Trends and techniques." IEEE
Communications magazine 38.5 (2000): 178-184.
[5] http://roy.gbiv.com/untangled/about, Roy T. Fielding’s private blog
[6] https://en.wikipedia.org/wiki/Representational_state_transfer, wikipedia