SlideShare a Scribd company logo

Grokking the REST Architectural Style

REST has become the hip, new buzzword of Web 2.0. But what makes an application RESTful? Pretty URLs? XML over HTTP? Any service that's not SOAP? In all the hype, the definition of REST has become clouded and diluted. Forget what you thought you knew about REST. In this talk, Ben Ramsey reintroduces REST, placing it under a microscope, uncovering each constraint that forms REST's crucial principles. Ramsey explains how REST is a style for network-based software applications, emphasizing scalability and efficiency through separation of concerns and taking advantage of the Web as a platform for rich Internet applications.

1 of 47
Download to read offline
Grokking the
REST Architectural Style


Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009
Yes.
I am this guy.
Roatan Beach - Perfect Day, by Janusz Leszczynski




REST
Is it about
pretty URLs?




        Tom Coates, by Patrick Lauke
#webdevgangsign




How about XML
 over HTTP?         Web Developer Gang Sign, by Josh Lewis
Any web service that’s
not SOAP?




                         A Bar of Ivory Soap, by iirraa

Recommended

You Look Like You Could Use Some REST!
You Look Like You Could Use Some REST!You Look Like You Could Use Some REST!
You Look Like You Could Use Some REST!Ben Ramsey
 
Memento: TimeGates, TimeBundles, and TimeMaps
Memento: TimeGates, TimeBundles, and TimeMapsMemento: TimeGates, TimeBundles, and TimeMaps
Memento: TimeGates, TimeBundles, and TimeMapsMichael Nelson
 
2017 dev nexus_deconstructing_rest_security
2017 dev nexus_deconstructing_rest_security2017 dev nexus_deconstructing_rest_security
2017 dev nexus_deconstructing_rest_securityDavid Blevins
 
2016 JavaOne Deconstructing REST Security
2016 JavaOne Deconstructing REST Security2016 JavaOne Deconstructing REST Security
2016 JavaOne Deconstructing REST SecurityDavid Blevins
 
Nltk natural language toolkit overview and application @ PyCon.tw 2012
Nltk  natural language toolkit overview and application @ PyCon.tw 2012Nltk  natural language toolkit overview and application @ PyCon.tw 2012
Nltk natural language toolkit overview and application @ PyCon.tw 2012Jimmy Lai
 
Website Latency Diagnostics
Website Latency DiagnosticsWebsite Latency Diagnostics
Website Latency DiagnosticsAlex Burciu
 
Natural Language Toolkit (NLTK), Basics
Natural Language Toolkit (NLTK), Basics Natural Language Toolkit (NLTK), Basics
Natural Language Toolkit (NLTK), Basics Prakash Pimpale
 

More Related Content

What's hot

Rest full
Rest fullRest full
Rest fullgfarid
 
HotPics 2021
HotPics 2021HotPics 2021
HotPics 2021neexemil
 
2017 JavaOne Deconstructing and Evolving REST Security
2017 JavaOne Deconstructing and Evolving REST Security2017 JavaOne Deconstructing and Evolving REST Security
2017 JavaOne Deconstructing and Evolving REST SecurityDavid Blevins
 
A Network Architecture for the Web of Things
A Network Architecture for the Web of ThingsA Network Architecture for the Web of Things
A Network Architecture for the Web of Thingsbenaam
 
Nltk natural language toolkit overview and application @ PyHug
Nltk  natural language toolkit overview and application @ PyHugNltk  natural language toolkit overview and application @ PyHug
Nltk natural language toolkit overview and application @ PyHugJimmy Lai
 
Covert Timing Channels using HTTP Cache Headers
Covert Timing Channels using HTTP Cache HeadersCovert Timing Channels using HTTP Cache Headers
Covert Timing Channels using HTTP Cache HeadersDenis Kolegov
 
Basic IT 2 (General IT Knowledge-2)
Basic IT 2 (General IT Knowledge-2)Basic IT 2 (General IT Knowledge-2)
Basic IT 2 (General IT Knowledge-2)kholis_mjd
 
Teach your (micro)services talk Protocol Buffers with gRPC.
Teach your (micro)services talk Protocol Buffers with gRPC.Teach your (micro)services talk Protocol Buffers with gRPC.
Teach your (micro)services talk Protocol Buffers with gRPC.Mihai Iachimovschi
 

What's hot (10)

Rest full
Rest fullRest full
Rest full
 
HotPics 2021
HotPics 2021HotPics 2021
HotPics 2021
 
2017 JavaOne Deconstructing and Evolving REST Security
2017 JavaOne Deconstructing and Evolving REST Security2017 JavaOne Deconstructing and Evolving REST Security
2017 JavaOne Deconstructing and Evolving REST Security
 
A Network Architecture for the Web of Things
A Network Architecture for the Web of ThingsA Network Architecture for the Web of Things
A Network Architecture for the Web of Things
 
Nltk natural language toolkit overview and application @ PyHug
Nltk  natural language toolkit overview and application @ PyHugNltk  natural language toolkit overview and application @ PyHug
Nltk natural language toolkit overview and application @ PyHug
 
Serialization in Go
Serialization in GoSerialization in Go
Serialization in Go
 
Just curl it!
Just curl it!Just curl it!
Just curl it!
 
Covert Timing Channels using HTTP Cache Headers
Covert Timing Channels using HTTP Cache HeadersCovert Timing Channels using HTTP Cache Headers
Covert Timing Channels using HTTP Cache Headers
 
Basic IT 2 (General IT Knowledge-2)
Basic IT 2 (General IT Knowledge-2)Basic IT 2 (General IT Knowledge-2)
Basic IT 2 (General IT Knowledge-2)
 
Teach your (micro)services talk Protocol Buffers with gRPC.
Teach your (micro)services talk Protocol Buffers with gRPC.Teach your (micro)services talk Protocol Buffers with gRPC.
Teach your (micro)services talk Protocol Buffers with gRPC.
 

Similar to Grokking the REST Architectural Style

Atom Web Services
Atom Web ServicesAtom Web Services
Atom Web Servicesthinkphp
 
Distribution and Publication With Atom Web Services
Distribution and Publication With Atom Web ServicesDistribution and Publication With Atom Web Services
Distribution and Publication With Atom Web ServicesBen Ramsey
 
Grokking REST (ZendCon 2010)
Grokking REST (ZendCon 2010)Grokking REST (ZendCon 2010)
Grokking REST (ZendCon 2010)Ben Ramsey
 
Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...
Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...
Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...ruyalarcon
 
Hidden Gems in HTTP
Hidden Gems in HTTPHidden Gems in HTTP
Hidden Gems in HTTPBen Ramsey
 
IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."
IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."
IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."Dongwook Lee
 
Interoperability Fundamentals: SWORD 2
Interoperability Fundamentals: SWORD 2Interoperability Fundamentals: SWORD 2
Interoperability Fundamentals: SWORD 2Adrian Stevenson
 
PHP Training: Module 1
PHP Training: Module 1PHP Training: Module 1
PHP Training: Module 1hussulinux
 
[DSBW Spring 2009] Unit 02: Web Technologies (1/2)
[DSBW Spring 2009] Unit 02: Web Technologies (1/2)[DSBW Spring 2009] Unit 02: Web Technologies (1/2)
[DSBW Spring 2009] Unit 02: Web Technologies (1/2)Carles Farré
 
Introduction to the World Wide Web
Introduction to the World Wide WebIntroduction to the World Wide Web
Introduction to the World Wide WebAbdalla Mahmoud
 
Have Some Rest Building Web2.0 Apps And Services
Have Some Rest   Building Web2.0 Apps And ServicesHave Some Rest   Building Web2.0 Apps And Services
Have Some Rest Building Web2.0 Apps And ServicesNenad Nikolic
 
REST in ( a mobile ) peace @ WHYMCA 05-21-2011
REST in ( a mobile ) peace @ WHYMCA 05-21-2011REST in ( a mobile ) peace @ WHYMCA 05-21-2011
REST in ( a mobile ) peace @ WHYMCA 05-21-2011Alessandro Nadalin
 
REST in peace @ IPC 2012 in Mainz
REST in peace @ IPC 2012 in MainzREST in peace @ IPC 2012 in Mainz
REST in peace @ IPC 2012 in MainzAlessandro Nadalin
 
HTTP 완벽가이드 1장.
HTTP 완벽가이드 1장.HTTP 완벽가이드 1장.
HTTP 완벽가이드 1장.HyeonSeok Choi
 
Intro to WebSockets and Comet
Intro to WebSockets and CometIntro to WebSockets and Comet
Intro to WebSockets and Cometdylanks
 

Similar to Grokking the REST Architectural Style (20)

Atom Web Services
Atom Web ServicesAtom Web Services
Atom Web Services
 
Distribution and Publication With Atom Web Services
Distribution and Publication With Atom Web ServicesDistribution and Publication With Atom Web Services
Distribution and Publication With Atom Web Services
 
Grokking REST (ZendCon 2010)
Grokking REST (ZendCon 2010)Grokking REST (ZendCon 2010)
Grokking REST (ZendCon 2010)
 
Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...
Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...
Fulfilling the Hypermedia Constraint via HTTP OPTIONS, The HTTP Vocabulary In...
 
HTTP & HTML & Web
HTTP & HTML & WebHTTP & HTML & Web
HTTP & HTML & Web
 
Hidden Gems in HTTP
Hidden Gems in HTTPHidden Gems in HTTP
Hidden Gems in HTTP
 
IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."
IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."
IBM dwLive, "Internet & HTTP - 잃어버린 패킷을 찾아서..."
 
Interoperability Fundamentals: SWORD 2
Interoperability Fundamentals: SWORD 2Interoperability Fundamentals: SWORD 2
Interoperability Fundamentals: SWORD 2
 
Starting With Php
Starting With PhpStarting With Php
Starting With Php
 
Sword v2 at UKCoRR
Sword v2 at UKCoRRSword v2 at UKCoRR
Sword v2 at UKCoRR
 
PHP Training: Module 1
PHP Training: Module 1PHP Training: Module 1
PHP Training: Module 1
 
HTTP1.1/2 overview
HTTP1.1/2 overviewHTTP1.1/2 overview
HTTP1.1/2 overview
 
[DSBW Spring 2009] Unit 02: Web Technologies (1/2)
[DSBW Spring 2009] Unit 02: Web Technologies (1/2)[DSBW Spring 2009] Unit 02: Web Technologies (1/2)
[DSBW Spring 2009] Unit 02: Web Technologies (1/2)
 
Introduction to the World Wide Web
Introduction to the World Wide WebIntroduction to the World Wide Web
Introduction to the World Wide Web
 
Have Some Rest Building Web2.0 Apps And Services
Have Some Rest   Building Web2.0 Apps And ServicesHave Some Rest   Building Web2.0 Apps And Services
Have Some Rest Building Web2.0 Apps And Services
 
REST in ( a mobile ) peace @ WHYMCA 05-21-2011
REST in ( a mobile ) peace @ WHYMCA 05-21-2011REST in ( a mobile ) peace @ WHYMCA 05-21-2011
REST in ( a mobile ) peace @ WHYMCA 05-21-2011
 
REST in peace @ IPC 2012 in Mainz
REST in peace @ IPC 2012 in MainzREST in peace @ IPC 2012 in Mainz
REST in peace @ IPC 2012 in Mainz
 
HTTP 완벽가이드 1장.
HTTP 완벽가이드 1장.HTTP 완벽가이드 1장.
HTTP 완벽가이드 1장.
 
Web Topics
Web TopicsWeb Topics
Web Topics
 
Intro to WebSockets and Comet
Intro to WebSockets and CometIntro to WebSockets and Comet
Intro to WebSockets and Comet
 

More from Ben Ramsey

Api Versioning
Api VersioningApi Versioning
Api VersioningBen Ramsey
 
Desktop Apps with PHP and Titanium (ZendCon 2010)
Desktop Apps with PHP and Titanium (ZendCon 2010)Desktop Apps with PHP and Titanium (ZendCon 2010)
Desktop Apps with PHP and Titanium (ZendCon 2010)Ben Ramsey
 
Introduction to AtomPub Web Services
Introduction to AtomPub Web ServicesIntroduction to AtomPub Web Services
Introduction to AtomPub Web ServicesBen Ramsey
 
Caching with Memcached and APC
Caching with Memcached and APCCaching with Memcached and APC
Caching with Memcached and APCBen Ramsey
 
Desktop Apps with PHP and Titanium
Desktop Apps with PHP and TitaniumDesktop Apps with PHP and Titanium
Desktop Apps with PHP and TitaniumBen Ramsey
 
Give Your Site a Boost with Memcache
Give Your Site a Boost with MemcacheGive Your Site a Boost with Memcache
Give Your Site a Boost with MemcacheBen Ramsey
 
Making the Most of HTTP In Your Apps
Making the Most of HTTP In Your AppsMaking the Most of HTTP In Your Apps
Making the Most of HTTP In Your AppsBen Ramsey
 
Around the PHP Community
Around the PHP CommunityAround the PHP Community
Around the PHP CommunityBen Ramsey
 
Distribution and Publication With Atom Web Services
Distribution and Publication With Atom Web ServicesDistribution and Publication With Atom Web Services
Distribution and Publication With Atom Web ServicesBen Ramsey
 

More from Ben Ramsey (9)

Api Versioning
Api VersioningApi Versioning
Api Versioning
 
Desktop Apps with PHP and Titanium (ZendCon 2010)
Desktop Apps with PHP and Titanium (ZendCon 2010)Desktop Apps with PHP and Titanium (ZendCon 2010)
Desktop Apps with PHP and Titanium (ZendCon 2010)
 
Introduction to AtomPub Web Services
Introduction to AtomPub Web ServicesIntroduction to AtomPub Web Services
Introduction to AtomPub Web Services
 
Caching with Memcached and APC
Caching with Memcached and APCCaching with Memcached and APC
Caching with Memcached and APC
 
Desktop Apps with PHP and Titanium
Desktop Apps with PHP and TitaniumDesktop Apps with PHP and Titanium
Desktop Apps with PHP and Titanium
 
Give Your Site a Boost with Memcache
Give Your Site a Boost with MemcacheGive Your Site a Boost with Memcache
Give Your Site a Boost with Memcache
 
Making the Most of HTTP In Your Apps
Making the Most of HTTP In Your AppsMaking the Most of HTTP In Your Apps
Making the Most of HTTP In Your Apps
 
Around the PHP Community
Around the PHP CommunityAround the PHP Community
Around the PHP Community
 
Distribution and Publication With Atom Web Services
Distribution and Publication With Atom Web ServicesDistribution and Publication With Atom Web Services
Distribution and Publication With Atom Web Services
 

Recently uploaded

"Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre...
"Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre..."Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre...
"Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre...shaiyuvasv
 
Curtain Module Manual Zigbee Neo CS01-1C.pdf
Curtain Module Manual Zigbee Neo CS01-1C.pdfCurtain Module Manual Zigbee Neo CS01-1C.pdf
Curtain Module Manual Zigbee Neo CS01-1C.pdfDomotica daVinci
 
Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24
Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24
Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24Umar Saif
 
How we think about an advisor tech stack
How we think about an advisor tech stackHow we think about an advisor tech stack
How we think about an advisor tech stackSummit
 
Introduction to Multimodal LLMs with LLaVA
Introduction to Multimodal LLMs with LLaVAIntroduction to Multimodal LLMs with LLaVA
Introduction to Multimodal LLMs with LLaVARobert McDermott
 
"Testing of Helm Charts or There and Back Again", Yura Rochniak
"Testing of Helm Charts or There and Back Again", Yura Rochniak"Testing of Helm Charts or There and Back Again", Yura Rochniak
"Testing of Helm Charts or There and Back Again", Yura RochniakFwdays
 
"Platform Engineering with Development Containers", Igor Fesenko
"Platform Engineering with Development Containers", Igor Fesenko"Platform Engineering with Development Containers", Igor Fesenko
"Platform Engineering with Development Containers", Igor FesenkoFwdays
 
Breaking Barriers & Leveraging the Latest Developments in AI Technology
Breaking Barriers & Leveraging the Latest Developments in AI TechnologyBreaking Barriers & Leveraging the Latest Developments in AI Technology
Breaking Barriers & Leveraging the Latest Developments in AI TechnologySafe Software
 
AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...
AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...
AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...ISPMAIndia
 
Building Products That Think- Bhaskaran Srinivasan & Ashish Gupta
Building Products That Think- Bhaskaran Srinivasan & Ashish GuptaBuilding Products That Think- Bhaskaran Srinivasan & Ashish Gupta
Building Products That Think- Bhaskaran Srinivasan & Ashish GuptaISPMAIndia
 
Zi-Stick UBS Dongle ZIgbee from Aeotec manual
Zi-Stick UBS Dongle ZIgbee from  Aeotec manualZi-Stick UBS Dongle ZIgbee from  Aeotec manual
Zi-Stick UBS Dongle ZIgbee from Aeotec manualDomotica daVinci
 
21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN
21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN
21ST CENTURY LITERACY FROM TRADITIONAL TO MODERNRonnelBaroc
 
Bit N Build Poland
Bit N Build PolandBit N Build Poland
Bit N Build PolandGDSC PJATK
 
IT Nation Evolve event 2024 - Quarter 1
IT Nation Evolve event 2024  - Quarter 1IT Nation Evolve event 2024  - Quarter 1
IT Nation Evolve event 2024 - Quarter 1Inbay UK
 
My self introduction to know others abut me
My self  introduction to know others abut meMy self  introduction to know others abut me
My self introduction to know others abut meManoj Prabakar B
 
Confoo 2024 Gettings started with OpenAI and data science
Confoo 2024 Gettings started with OpenAI and data scienceConfoo 2024 Gettings started with OpenAI and data science
Confoo 2024 Gettings started with OpenAI and data scienceSusan Ibach
 
AI Act & Standardization: UNINFO involvement
AI Act & Standardization: UNINFO involvementAI Act & Standardization: UNINFO involvement
AI Act & Standardization: UNINFO involvementMimmo Squillace
 
From Challenger to Champion: How SpiraPlan Outperforms JIRA+Plugins
From Challenger to Champion: How SpiraPlan Outperforms JIRA+PluginsFrom Challenger to Champion: How SpiraPlan Outperforms JIRA+Plugins
From Challenger to Champion: How SpiraPlan Outperforms JIRA+PluginsInflectra
 
Leveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docx
Leveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docxLeveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docx
Leveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docxVotarikari Shravan
 
Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?
Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?
Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?GleecusTechlabs1
 

Recently uploaded (20)

"Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre...
"Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre..."Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre...
"Journey of Aspiration: Unveiling the Path to Becoming a Technocrat and Entre...
 
Curtain Module Manual Zigbee Neo CS01-1C.pdf
Curtain Module Manual Zigbee Neo CS01-1C.pdfCurtain Module Manual Zigbee Neo CS01-1C.pdf
Curtain Module Manual Zigbee Neo CS01-1C.pdf
 
Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24
Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24
Progress Report: Ministry of IT under Dr. Umar Saif Aug 23-Feb'24
 
How we think about an advisor tech stack
How we think about an advisor tech stackHow we think about an advisor tech stack
How we think about an advisor tech stack
 
Introduction to Multimodal LLMs with LLaVA
Introduction to Multimodal LLMs with LLaVAIntroduction to Multimodal LLMs with LLaVA
Introduction to Multimodal LLMs with LLaVA
 
"Testing of Helm Charts or There and Back Again", Yura Rochniak
"Testing of Helm Charts or There and Back Again", Yura Rochniak"Testing of Helm Charts or There and Back Again", Yura Rochniak
"Testing of Helm Charts or There and Back Again", Yura Rochniak
 
"Platform Engineering with Development Containers", Igor Fesenko
"Platform Engineering with Development Containers", Igor Fesenko"Platform Engineering with Development Containers", Igor Fesenko
"Platform Engineering with Development Containers", Igor Fesenko
 
Breaking Barriers & Leveraging the Latest Developments in AI Technology
Breaking Barriers & Leveraging the Latest Developments in AI TechnologyBreaking Barriers & Leveraging the Latest Developments in AI Technology
Breaking Barriers & Leveraging the Latest Developments in AI Technology
 
AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...
AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...
AI MODELS USAGE IN FINTECH PRODUCTS: PM APPROACH & BEST PRACTICES by Kasthuri...
 
Building Products That Think- Bhaskaran Srinivasan & Ashish Gupta
Building Products That Think- Bhaskaran Srinivasan & Ashish GuptaBuilding Products That Think- Bhaskaran Srinivasan & Ashish Gupta
Building Products That Think- Bhaskaran Srinivasan & Ashish Gupta
 
Zi-Stick UBS Dongle ZIgbee from Aeotec manual
Zi-Stick UBS Dongle ZIgbee from  Aeotec manualZi-Stick UBS Dongle ZIgbee from  Aeotec manual
Zi-Stick UBS Dongle ZIgbee from Aeotec manual
 
21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN
21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN
21ST CENTURY LITERACY FROM TRADITIONAL TO MODERN
 
Bit N Build Poland
Bit N Build PolandBit N Build Poland
Bit N Build Poland
 
IT Nation Evolve event 2024 - Quarter 1
IT Nation Evolve event 2024  - Quarter 1IT Nation Evolve event 2024  - Quarter 1
IT Nation Evolve event 2024 - Quarter 1
 
My self introduction to know others abut me
My self  introduction to know others abut meMy self  introduction to know others abut me
My self introduction to know others abut me
 
Confoo 2024 Gettings started with OpenAI and data science
Confoo 2024 Gettings started with OpenAI and data scienceConfoo 2024 Gettings started with OpenAI and data science
Confoo 2024 Gettings started with OpenAI and data science
 
AI Act & Standardization: UNINFO involvement
AI Act & Standardization: UNINFO involvementAI Act & Standardization: UNINFO involvement
AI Act & Standardization: UNINFO involvement
 
From Challenger to Champion: How SpiraPlan Outperforms JIRA+Plugins
From Challenger to Champion: How SpiraPlan Outperforms JIRA+PluginsFrom Challenger to Champion: How SpiraPlan Outperforms JIRA+Plugins
From Challenger to Champion: How SpiraPlan Outperforms JIRA+Plugins
 
Leveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docx
Leveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docxLeveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docx
Leveraging SLF4j for Effective Logging in IBM App Connect Enterprise.docx
 
Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?
Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?
Unlocking the Cloud's True Potential: Why Multitenancy Is The Key?
 

Grokking the REST Architectural Style

  • 1. Grokking the REST Architectural Style Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009
  • 3. Roatan Beach - Perfect Day, by Janusz Leszczynski REST
  • 4. Is it about pretty URLs? Tom Coates, by Patrick Lauke
  • 5. #webdevgangsign How about XML over HTTP? Web Developer Gang Sign, by Josh Lewis
  • 6. Any web service that’s not SOAP? A Bar of Ivory Soap, by iirraa
  • 7. Representational State Transfer Restful Summer, by Clear Inner Vision
  • 8. Public Domain, from Wikimedia Commons Theory of REST
  • 9. REST defines a style by which a resource’s state may be transferred using a representation of that resource.
  • 11. Stateless Stateless by Koesmanto Bong
  • 12. Cache Cache County, Utah by J. Stephen Conn
  • 13. 1.Identification of resources 2.Representation of resources 3.Linked resources 4.Resource metadata Uniform Interface used to interface, by Tom Hensel
  • 14. Layered Sedimentary Layers by Mark Thurman
  • 15. jeremyʼs tie by Gitchel Code-on-demand
  • 16. RESTful Benefits Improved response time & reduced server load Improves server scalability Requires less client-side software Depends less on vendor software No need for resource discovery Better long-term compatibility & evolvability than RPC Sand Banks Sunset, by Clear Inner Vision
  • 17. A Real-World Analogy Money!, by Tracy Olson
  • 18. RESTful Practice Public Domain, from Wikimedia Commons
  • 19. “[REST] is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.” — Roy Fielding Drip Drops and the Spider Web, by Mike Bitzenhofer
  • 20. Hypertext Transfer Protocol URIs provide unique addresses Constrained interface with methods and content types Transactions are atomic Built-in support for layering Provides for cache control #110 Hypertext Transfer Protocol, by maako
  • 21. HTTP Interface Methods Cut & Paste GET Copy PUT Paste Over POST Paste After DELETE Cut #110 Hypertext Transfer Protocol, by maako
  • 22. Content Types HTTP supports content types through the Content-Type header A single resource can be transferred in various content types Content negotiation used to tell the server what type to return to the client REST community doesn’t care for content negotiation #110 Hypertext Transfer Protocol, by maako
  • 23. Lifecycle of a Resource 1 POST /content HTTP/1.1 Host: example.org Content-Type: application/xml 2 HTTP/1.x 201 Created Date: Thu, 13 November 2008 16:43:56 GMT Location: /content/1234 #110 Hypertext Transfer Protocol, by maako
  • 24. Lifecycle of a Resource 3 GET /content/1234 HTTP/1.1 Host: example.org 4 HTTP/1.x 200 OK Date: Thu, 13 November 2008 16:44:13 GMT Content-Type: application/xml #110 Hypertext Transfer Protocol, by maako
  • 25. Lifecycle of a Resource 5 PUT /content/1234 HTTP/1.1 Host: example.org Content-Type: application/xml 6 HTTP/1.x 200 OK Date: Thu, 13 November 2008 16:48:26 GMT Content-Type: application/xml #110 Hypertext Transfer Protocol, by maako
  • 26. Lifecycle of a Resource 7 DELETE /content/1234 HTTP/1.1 Host: example.org 8 HTTP/1.x 204 No Content Date: Thu, 13 November 2008 16:50:47 GMT #110 Hypertext Transfer Protocol, by maako
  • 27. Resource-oriented Architecture 1. Represent itself to the client 2. Transition from one state to the next 3. Destroy itself Additionally, the system knows how to create a resource. Where I Teach, by Todd Ehlers
  • 28. Resource-oriented Architecture Resources are addressable Resources have no state Resources are connected Resources share the same interface Where I Teach, by Todd Ehlers
  • 29. Resource-oriented Architecture Query string parameters appropriate in some cases Pragmatic use of URIs instead of using HTTP headers RPC-style APIs are avoided Representation should have links URI templates specify URI families Where I Teach, by Todd Ehlers
  • 30. Resource-oriented Architecture Should expose many URIs Session cookies are not RESTful Combined resources are RESTful only if represented as a URI URIs should facilitate “cut & paste” Where I Teach, by Todd Ehlers
  • 31. Atom A resource-oriented protocol for publishing documents that sits on top of HTTP Molecule display, by Christian Guthier
  • 32. Atom Entry Document application/atom+xml;type=entry Feed (Collection) Document application/atom+xml;type=feed Category Document application/atomcat+xml Service Document application/atomsvc+xml Molecule display, by Christian Guthier
  • 33. Atom Resource Lifecycle 1 GET /index.atom HTTP/1.1 Host: example.org 2 HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:13:14 GMT Content-Type: application/atomsvc+xml Molecule display, by Christian Guthier
  • 34. Atom Resource Lifecycle 3 GET /archives.atom HTTP/1.1 Host: example.org 4 HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:13:46 GMT Content-Type: application/atom+xml;type=feed Molecule display, by Christian Guthier
  • 35. Atom Resource Lifecycle 5 GET /categories.atom HTTP/1.1 Host: example.org 6 HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:13:48 GMT Content-Type: application/atomcat+xml Molecule display, by Christian Guthier
  • 36. Atom Resource Lifecycle 7 POST /archives.atom HTTP/1.1 Host: example.org Content-Type: application/atom+xml;type=entry 8 HTTP/1.x 201 Created Date: Thu, 13 November 2008 17:16:32 GMT Location: /archives/1234.atom Molecule display, by Christian Guthier
  • 37. Atom Resource Lifecycle 9 GET /archives/1234.atom HTTP/1.1 Host: example.org 10 HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:16:36 GMT Content-Type: application/atom+xml;type=entry Molecule display, by Christian Guthier
  • 38. Atom Resource Lifecycle 11 PUT /archives/1234.atom HTTP/1.1 Host: example.org Content-Type: application/atom+xml;type=entry 12 HTTP/1.x 200 OK Date: Thu, 13 November 2008 17:23:12 GMT Content-Type: application/atom+xml;type=entry Molecule display, by Christian Guthier
  • 39. Atom Resource Lifecycle 13 DELETE /archives/1234.atom HTTP/1.1 Host: example.org 14 HTTP/1.x 204 No Content Date: Thu, 13 November 2008 19:34:29 GMT Molecule display, by Christian Guthier
  • 40. Resource-oriented Design 1. Determine your resources User Content /users /content /users/{username} /content/{ID} Before we had CAD, we had Lead!, by Wendell
  • 41. Resource-oriented Design 2. Decide the methods for each resource /users /users/{username} /content /content/{ID} GET GET GET GET POST PUT POST PUT DELETE DELETE Before we had CAD, we had Lead!, by Wendell
  • 42. Resource-oriented Design 3. Link your resources Users own content Each user owns multiple content items Each content item has one owner Before we had CAD, we had Lead!, by Wendell
  • 43. Resource-oriented Design 4. Determine your data schemas User Content id id username owner firstname title lastname file/content Before we had CAD, we had Lead!, by Wendell
  • 44. Resource-oriented Design 5. Choose your content type(s) Before we had CAD, we had Lead!, by Wendell
  • 45. In conclusion... Conclusion, by Mark Cummins
  • 47. Grokking the REST Architectural Style Copyright © Ben Ramsey. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License. For uses not covered under this license, please contact the author.

Editor's Notes

  1. Is REST about so-called “pretty” URLs? Tom Coates, who apparently made this statement at a “Future of Web Apps” summit.
  2. If you want to be real cool, take a pic of yourself doing this and post it to Flickr with the tag “webdevgangsign.”
  3. Or not RPC (remote procedure call)?
  4. * Representational State Transfer * Term originated in 2000 in Roy Fielding’s doctoral dissertation about the Web entitled “Architectural Styles and the Design of Network-based Software Architectures” * Not an architecture or a standard for developing web services * Not a particular format or pattern * It is a set of design principles
  5. There are six major constraints that define the REST architectural style.
  6. There are six major constraints that define the REST architectural style.
  7. There are six major constraints that define the REST architectural style.
  8. There are six major constraints that define the REST architectural style.
  9. The client-server relationship provides for a separation of concerns. This separation is very important to REST. IMO, it’s perhaps the most important constraint. We’re all-too-familiar with the client-server relationship, since it’s how the Web works, but it’s also what makes the other REST constraints possible and beneficial.
  10. What is a resource? From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.” All resources share a uniform interface for the transfer of state between client and resource, consisting of - A constrained set of well-defined operations - A constrained set of content types, optionally supporting code on demand
  11. What is a resource? From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.” All resources share a uniform interface for the transfer of state between client and resource, consisting of - A constrained set of well-defined operations - A constrained set of content types, optionally supporting code on demand
  12. What is a resource? From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.” All resources share a uniform interface for the transfer of state between client and resource, consisting of - A constrained set of well-defined operations - A constrained set of content types, optionally supporting code on demand
  13. What is a resource? From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.” All resources share a uniform interface for the transfer of state between client and resource, consisting of - A constrained set of well-defined operations - A constrained set of content types, optionally supporting code on demand
  14. Advocates claim that REST: * Provides improved response time and reduced server load due to its support for the caching of representations * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP * Provides equivalent functionality when compared to alternative approaches to communication * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to: - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types. One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
  15. Advocates claim that REST: * Provides improved response time and reduced server load due to its support for the caching of representations * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP * Provides equivalent functionality when compared to alternative approaches to communication * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to: - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types. One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
  16. Advocates claim that REST: * Provides improved response time and reduced server load due to its support for the caching of representations * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP * Provides equivalent functionality when compared to alternative approaches to communication * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to: - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types. One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
  17. Advocates claim that REST: * Provides improved response time and reduced server load due to its support for the caching of representations * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP * Provides equivalent functionality when compared to alternative approaches to communication * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to: - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types. One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
  18. Advocates claim that REST: * Provides improved response time and reduced server load due to its support for the caching of representations * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP * Provides equivalent functionality when compared to alternative approaches to communication * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to: - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types. One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
  19. Advocates claim that REST: * Provides improved response time and reduced server load due to its support for the caching of representations * Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session * Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource * Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP * Provides equivalent functionality when compared to alternative approaches to communication * Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations * Provides better long-term compatibility and evolvability characteristics than RPC. This is due to: - The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility - The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types. One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
  20. Humans live in the world of representations. Representation, as a concept, is an attempt (arguably futile) to reach certain acceptable level of objectivity. For example, if a person wants to buy a house, that person needs to qualify for a mortgage. If that person explains to the mortgage broker that he has $50,000.00 cash available for the down payment toward purchasing the house, the broker will not go ahead and approve the mortgage, even though the quoted amount would be fully satisfactory. What the mortgage broker needs is a more objective argument that would reassure the issuer that the party asking for the mortgage does indeed have enough money for the down payment. But how is the issuer to go about obtaining the more objective proof? Certainly not by going directly into the applicant's safety vault and counting the money deposited there. Instead, the issuer is simply expecting to receive a representation of that person's balance in his bank account. That representation projects a sufficient illusion of objectivity, so that the involved parties could sufficiently relax and that the business transaction can eventually take place. In the same manner, any transaction that transpires on the web is based on the similar representational logic. The actual resource is never being touched. Instead, various representations of the said resource are being prepared, rendered, and shipped to the clients for consumption. Same as in the real world, where the mortgage issuer will never actually touch client's money, but will instead be satisfied with a mere piece of paper representing the balance, resources on the web never get to be directly manipulated by the clients.
  21. URIs uniquely address resources HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface All transactions are atomic HTTP provides cache control HTTP provides layering
  22. URIs uniquely address resources HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface All transactions are atomic HTTP provides cache control HTTP provides layering
  23. URIs uniquely address resources HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface All transactions are atomic HTTP provides cache control HTTP provides layering
  24. URIs uniquely address resources HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface All transactions are atomic HTTP provides cache control HTTP provides layering
  25. URIs uniquely address resources HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface All transactions are atomic HTTP provides cache control HTTP provides layering
  26. URIs uniquely address resources HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface All transactions are atomic HTTP provides cache control HTTP provides layering