The document discusses the evolution of web services, particularly focusing on the Representational State Transfer (REST) architectural style and its applications. It outlines various web service frameworks, history of web development, and principles of REST, including resource-oriented architecture, HTTP methods, and uniform interfaces. Additionally, it provides examples of HTTP methods like GET, POST, PUT, and DELETE, and emphasizes the importance of sensible resource naming and API design.

1. RESTful Web
from RESTful style to RESTful code work
!
!
!
@PengEdy

2. 2
Table of Contents
• Web & Web Service
!
• Details of REST Style
!
• Some Examples

3. 3
Web & Web Service

4. 4
Web Service
• Normally: a method of communications over the WWW
!
• W3C Definition: a software system
• Designed to support interoperable machine-to-machine interaction
• Over network
• An interface with a certain format: WSDL
• Other systems interact with the Web Service

5. 5
The ways we are using web service:
• RPC: Remote Procedure Call
• Strong Coupling
• SOA: Service-oriented Architecture
• This is a good choice.
• REST: Representational State Transfer
• Another choice

6. 6
Demo of RPC
• Server
getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
• Client
exampleAppObject = new
ExampleApp(“example.com:
1234”)
exampleAppObject.getUser()

7. 7
Demo of REST
• Server
http://example.com/users/
http://example.com/users/
{user}
http://example.com/
findUserForm
http://example.com/locations
http://example.con/locations/
{location}
http://example.com/
findLocationForm
• Client
userResource = new
Resource(http://
example.com/users/001)
userResource.get()

8. 8
Our Web…
• Human Web
• For normal users
• Website, Web Application, etc.
• Programmable Web
• For program/programmer
• A set of API

9. 9
Web History
• Stage 1: Static Content
• At the beginning of web
• Full of static HTML content, which is the papers made by the scholar
• Like a file sharing server supports Hypertext
!
• Is that enough ? We want MORE !

10. 10
Web History
• Stage 2: CGI Program
• People wanted to have more function on the web.
• API appeared.
• CGI is made by C/C++, Perl, and some other language, which is
powerful but a little tricky.
!
• But, we want it better…

11. 11
Web History
• Stage 3: Script Languages
• CGI is not safe, so we have script languages.
• ASP, JSP, PHP, Java Applet, JavaScript, etc…
• HTML was mixed with scripts, which is much more safe and powerful.
!
• Well, it was still tricky for developers with pure scripts.
• The mixture of HTML and script was horrible when code increased.
!
• And, we want more !

12. 12
Web History
• Stage 4: Thin Client
• All the content was produced on the server.
• And we had MVC !
• Back-end technology runs fast in this stage.
!
• Still, we want more !

13. 13
Web History
• Stage 5: Rich Interactive Application (RIA)
• Developers started to build single page application, which can be very
useful on the desktop.
• Front-end technology started to run.
• Ajax, jQuery/jQuery UI, ExtJS, Prototype, etc…
• Flex, Sliverlight, JavaFX
• ……
!
• Always, we want more !

14. 14
Web History
• Stage 6: Mobile Application
• RIA is great, we now have something greater — mobile web.
• iOS, Android, Windows Phone, Blackberry, etc..
• HTML5 + CSS3 + JavaScript
!
• We are happy with it now, while we both know that’s not enough.

15. 15
Web NOW !
• Pure HTML is not enough.
• CGI and scripts suck.
• Developers, users, administrators want to be happy !
!
• So, we have made our mind and technology improved:
• Resource Oriented
• HTTP 1.1: request method, status code, cache
• REST

16. 16
RESTful and Resource Oriented Architecture
• REST: Representational State Transfer
• a style, not a standerd
• ROA
• What is resource: anything useful
• Resources must have URIs.
• Use HTTP verbs to implement CRUD
• Provide 2 kind of web service
• Human Web
• Programmable Web

17. 17
HTTP Request Methods
• Verbs:
• OPTIONS
• HEAD
• GET
• POST
• PUT
• DELETE
• TRACE
• CONNECT
• PATCH

18. 18
HTTP Request Methods
• Safe method: just get information, doesn’t change anything.
• GET, HEAD
• Idempotent methods: multiple identical requests should have the same
effect as a single request.
• GET, HEAD, PUT, DELETE, OPTIONS, TRACE
!
• We focus on: GET, POST, DELETE, PUT

19. 19
Details of REST Style

20. 20
Build REST from Everything
• There are two thoughts when we want build something:
• Nothing we have, we start from bringing in.
• Everything we have, we start from cutting down.
!
• For REST, the author made some cut off on the former web style.

21. 21
RESTful Binding
• Client-Server
• Separate the system into client and server
• Client call request, send it to server

22. 22
RESTful Binding
• Stateless
• Request shall contain all the information it needs.
• Server identify requests by the info it stored in, not some info on the
server.

23. 23
RESTful Binding
• Cacheable
• Data in the request should marked as either cacheable or not, in a
sensitive or insensitive way, so that client can cache the data.

24. 24
RESTful Binding
• Uniform Interface
• Optimize the structure
• Light coupling

25. 25
RESTful Binding
• Layered System
• Simplify the system
• Make high performance possible

26. 26
RESTful Binding
• Code on Demand
• Expand system

27. 27
REST Quick Tips
• Use HTTP Verbs to mean something: GET, PUT, DELETE, POST
• Provide sensible resource names
• Use HTTP response code to indicate status
• Offer JSON and XML

28. 28
HTTP Methods
• We will only discuss the most useful four methods here:
• GET
• PUT
• POST
• DELETE

29. 29
HTTP Methods: GET
# Add bookmark
GET /bookmarks/add_bookmark?href=http%3A%2F%2F
www.example.org%2F2009%2F10%2F10%2Fontes.html HTTP/1.1
Host: www.example.org
# Add cart
GET /add_cart?pid=1234 HTTP/1.1
Host: www.example.org
# Delete note
GET /notes/delete?id=1234 HTTP/1.1
Host: www.example.org

30. 30
HTTP Methods: PUT
• PUT will only be used when client can decide the URI or resource.
!
# Request
PUT /user/smith/address/home_address HTTP/1.1
Host: www.example.com
Content-type: application/xml;charset=UTF-8
<address>
<street>1, Main Street</street>
<city>New York</city>
</address>

31. 31
HTTP Methods: PUT
# Response
HTTP/1.1 201 Created
Location: http://www.example.org/user/smith/address/home_address
Content-Location: http://www.example.org/user/smith/address/home_address
Content-Type: application/xml;charset=UTF-8
<address>
<id>urn:example:user:smith:address:1</id>
<atom>link rel=“self” href=“http://www.example.org/user/smith/address/
home_address”/>
<street>1, Main Street</street>
<city>New York</city>
</address>

32. 32
HTTP Methods: POST
• Create new resource if we don’t
know the URI
• Update resource(s) using controller
• Run research which has too many
parameters
• Other actions which are not safe
# Request
POST /user/smith HTTP/1.1
Host: www.example.com
Content-type: application/xml;charset=UTF-8
Slug: Home Address
<address>
<street>1, Main Street</street>
<city>New York</city>
</address>

33. 33
HTTP Methods: POST
# Response
HTTP/1.1 201 Created
Location: http://www.example.org/user/smith/address/home_address
Content-Location: http://www.example.org/user/smith/address/home_address
Content-Type: application/xml;charset=UTF-8
<address>
<id>urn:example:user:smith:address:1</id>
<atom>link rel=“self” href=“http://www.example.org/user/smith/address/
home_address”/>
<street>1, Main Street</street>
<city>New York</city>
</address>

34. 34
HTTP Methods: DELETE
• DELETE a resource on the web.
!
# Request
DELETE /users/john HTTP/1.1
Host: www.example.com

35. 35
Resource Naming
• To name a resource to make it readable and programmable
• URI: the name of resource as well as an address on the web
• A RESTful URI should refer to a resource that is a thing, not an action.
• Resource:
• Users of the system
• Courses in which a student is enrolled
• A user’s timeline of posts
• The users that follow another user (some kind of relationship)
• An article or a news on the web
• etc…

36. 36
Resource Naming
• Some examples:
• To insert/create a new customer in the system:
• POST http://example.com/customers
• To read a customer with Customer ID #12345
• GET http://example.com/customers/12345
• the same URI would be used for PUT & DELETE, to update and delete
• For reading , updating, deleting, product #12345:
• GET/PUT/DELETE http://example.com/pruducts/12345

37. 37
Resource Naming
• More examples:
• To create an order for a customer:
• POST http://example.com/customers/12345/orders
• GET http://example.com/customers/12345/orders
• What will it return ?
• POST http://example.com/customers/12345/orders/2334/lineitems
• What will this return ?

38. 38
Resource Naming
• More and more real examples:
• Twitter: https://dev.twitter.com/docs/api
• Facebook: http://develpoers.facebook.com/docs/api/
• LinkedIn: https://developer.linkedin.com/apis
• more…

39. 39
RESTful API Demo

40. 40
Build a website

41. 41
Build a set of API

42. 42
Programming Languages and Frameworks
• Java
• PHP
• Python
• Ruby
• JavaScript (Node.js)
• C#
• etc…

43. 43
Thanks for your listening !