The document discusses the basics of web operations using the HTTP API. It explains the four main HTTP operations - GET, POST, PUT, and DELETE and their properties and typical usages. It also provides an overview of REST (Representational State Transfer) and how it uses HTTP and URIs to access resources in a stateless manner through representations. The key constraints that define REST including using a uniform interface, separating resources and representations, and making communications self-descriptive are also summarized.

2. Web Basics:
Operations, via the HTTP
API
0 HTTP provides a simple set of operations. Amazingly, all
Web exchanges are done using this simple HTTP API:
0 GET
0 Properties: Safe, Idempotent
0 Usage: Retrieving a resource
0 POST
0 Properties: UNSAFE
0 Creating a resource within a collection (resource URI unknown)
0 PUT
0 Properties: Idempotent
0 Usage: Creating or updating a resource at a known URI
0 DELETE
0 Properties: Idempotent
0 Usage: Deleting a resource
2 Umme Habiba: KTH-Applied Information Security Lab SEECS

3. Resource Oriented Architecture?
0 ROA is the term for REST on HTTP/URI
0 A Service consists of all the resources available within a
certain domain of control
0 Since REST is a type of SOA, ROA is an implementation of
SOA as well.
Umme Habiba: KTH-Applied Information Security Lab SEECS

4. Web Basics: Simple Set of
Operations, via the HTTP API
Desired HTTP Header
action
Target
POST / HTTP/1.1 Machine
Host: ttp://www.amazon.com
Book: DaVince Code Book: Da Vince Code HTTP
Credit Card: Visa
Number: 123-45-6789 Credit Card: Visa Payload
Expiry: 12-04-06
Number: 123-45-6789
Expiry: 12-04-06 Amazon
Web Server
Data being
Posted
4 Umme Habiba: KTH-Applied Information Security Lab SEECS

5. REST
Roy Fielding described REST as an architecture style which
attempts “to minimize latency and network communication, while
at the same time maximizing the independence and scalability of
component implementations"
5 Umme Habiba: KTH-Applied Information Security Lab SEECS

6. REST - Not a Standard
0 REST is not a standard
0 REST is just a design pattern
0 REST does prescribe the use of standards:
0 HTTP
0 URL
0 XML/HTML/GIF/JPEG/etc. (Resource Representations)
0 text/xml, text/html, image/gif, image/jpeg, etc. (Resource
Types, MIME Types)
6 Umme Habiba: KTH-Applied Information Security Lab SEECS

7. Why is it called
"Representational State Transfer? "
http://www.boeing.com/aircraft/747
Client Resource
Fuel requirements
Maintenance schedule
...
Boeing747.html
The Client references a Web resource using a URL.
A representation of the resource is returned (in this case as an HTML document).
The representation (e.g., Boeing747.html) places the client in a new state.
When the client selects a hyperlink in Boeing747.html, it accesses another resource.
The new representation places the client application into yet another state.
Thus, the client application transfers state with each resource representation.
7 Umme Habiba: KTH-Applied Information Security Lab SEECS

8. REST Constraints
0 Important ‘things’ (Noun) are Resources
0 Addressed through a URI
0 Uniform interface (Verb)
0 In HTTP: GET, PUT, POST, DELETE
0 Verb-Noun separation makes integration easier
0 GET /customer/45
Instead of getCustomer(45) OR viewCustomer(45) OR showCustomer(45)
8 Umme Habiba: KTH-Applied Information Security Lab SEECS

9. REST
0 Create a resource for every service.
0 Separation of resource from representation
0 The data that a Web service returns should link to other data.
0 Resources are identified by URIs
0 Resources are manipulated through their representations
0 Self-descriptive messages
9
Umme Habiba: KTH-Applied Information Security Lab SEECS

10. Why not plain HTML?
0 Web pages are designed to be understood by people,
0 layout and styling do matter, not just raw data
0 Every URI could have a human-readable and a machine-
process-able representation:
0 Web Services clients ask for the machine-readable one
0 Browsers ask for the human-readable.
0 A web page is a representation of a resource
0 URIs tell a client that there's a concept somewhere
0 Clients can then request a specific representation of the
concept from the representations the server makes
available
10 Umme Habiba: KTH-Applied Information Security Lab SEECS

11. Why hypertext?
0 Because the links mirror the structure of how a user
makes progress through an application
0 The user is in control, thanks to the Back button and
other non-local actions
0 In a Web service, the client should be in control in the
same sense
<order self='http://example.com/customers/1234' >
<amount>23</amount>
<product ref='http://example.com/products/4554' />
<customer ref='http://example.com/customers/1234' />
</order>
11 Umme Habiba: KTH-Applied Information Security Lab SEECS

12. What is REST??
0 Uniform Interface
0 Stateless
0 Cacheable
0 Client-Server
0 Layered System
0 Code on Demand (Optional)
12 Umme Habiba: KTH-Applied Information Security Lab SEECS

13. Uniform Interface
0 Simplifies & decouples Architecture for better visibility &
evovlability.
0 Resource based representation
0 Manipulation of resources through representations
0 Self-descriptive messages
0 Principle of Generality on Interface
0 Con: Degrades efficiency
0 Optimized: Large grain hypermedia transfer
13 Umme Habiba: KTH-Applied Information Security Lab SEECS

14. Client Server
0 Separation of Concerns
0 Improve Portability of UI
0 Scalability per simple server components
0 Independent evolution
14 Umme Habiba: KTH-Applied Information Security Lab SEECS

15. Cache
0 Eliminates Client server Interactions, partially or completely
0 Improves Scalability and performance
0 Reduced latency in average
0 Con: Decrease on reliability, cached data may not be the
recently updated
15 Umme Habiba: KTH-Applied Information Security Lab SEECS

16. Layered System
0 Restrict knowledge of system to 1 layer
0 Bounds systems complexity + Encapsulation
0 Intermediaries and load balancing
0 Con: Add overhead and latency
0 Optimized: Pipes & Filters behavior with intermediaries
processing partially the message
16 Umme Habiba: KTH-Applied Information Security Lab SEECS

17. Stateless
0 Statelessness is the key.
0 Necessary state is contained in the request itself.
0 Prevents partial failures
0 No context in server, session in client
0 Visibility, reliability, and scalability
0 Con: Decrease network performance
17 Umme Habiba: KTH-Applied Information Security Lab SEECS

18. Code On Demand (Optional)
0 Temporary extend or customize client functionality
(extensibility- java scripts and java applets)
0 Client simplification
0 Con: Reduces visibility
0 This is the only optional constrain
18 Umme Habiba: KTH-Applied Information Security Lab SEECS

19. Who is using REST?
0 Google
0 GData, OpenSocial
0 Standards
0 Atom, WebDAV
0 Amazon
0 S3, SimpleDB
0 Microsoft (!)
0 Project Astoria, Web3S
19 Umme Habiba: KTH-Applied Information Security Lab SEECS

20. Advantages of REST
0 Its architectural constraints when applied as a whole, generate:
0 Scalable component interactions
0 General interfaces
0 Independently deployed connectors
0 Reduced interaction latency
0 Strengthened security
0 Safe encapsulation of legacy systems
0 Separates server implementation from the client's perception
of resources
0 Scales well to large numbers of clients
0 Enables transfer of data in streams of unlimited size and type
20 Umme Habiba: KTH-Applied Information Security Lab SEECS

21. Thank You
21