• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
335
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
8
Comments
1
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. RESTful Web Architecture Shritesh Bhattarai @shritesh
  • 2. The Situation • Websites have become apps. • Multitude of platforms to develop for. • Excessively data driven. • Lots of external service integrations.
  • 3. The Problem • Different systems for the ‘website’ and the ‘app’. • Reinventing the wheel, over and over. • Lack of well-thought architecture. • HTTP over HTTP.
  • 4. Hypertext Transfer Protocol Client Server GET /index.html HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT ETag: "3f80f-1b6-3e1cb03b" Content-Type: text/html; charset=UTF-8 Content-Length: 131 Accept-Ranges: bytes Connection: close ! <html> <head> <title>An Example Page</title> </head> <body> Hello World, this is a very simple HTML document. </body> </html>
  • 5. HTTP • Method: GET / HEAD / POST / PUT / DELTE / … • Path: Address to a resource (identifier) • Header: Host: example.com, … • Status code: 200 OK, 404 Not found • Body: Hello World
  • 6. The Example App A todo app (Hello world for web programming)
  • 7. The Resource • ToDo List Item • Contents: • id • title • done • created_at • updated_at
  • 8. The Interface • Methods map to their HTTP headers • Create: POST • Read: GET • Update: PUT / PATCH • Delete: DELETE
  • 9. The Interface • The URIs point to specific resource • /todo : Collection of todos • /todo/id : a specific todo
  • 10. The Representation of the Resource
  • 11. The Statelessness • Every request is self contained • Information is stored on the header
  • 12. REST REpresentational State Transfer • Uniform Interface • Stateless • Cacheable • Client-Server • Layered System • Code-on-demand (optional)
  • 13. Why REST? • A time tested architecture. • Both machine and human friendly. • Made for the web.
  • 14. Thank you