1 / 23

RESTfulness

RESTfulness. CS 4720 – Web & Mobile Systems. And verily the Intarwebz were created. The evolution of the web Server / Client Simple pages Web applications. And verily the Intarwebz were created. And verily the Intarwebz were created. And verily the Intarwebz were created.

nyx
Download Presentation

RESTfulness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RESTfulness CS 4720 – Web & Mobile Systems

  2. And verily the Intarwebz were created • The evolution of the web • Server / Client • Simple pages • Web applications 2

  3. And verily the Intarwebz were created 3

  4. And verily the Intarwebz were created 4

  5. And verily the Intarwebz were created 5

  6. The Statefulness… or lack there of… • How does state play into SIS? • Why? How? 6

  7. Nouns speak louder than… verbs… • Look at the links in SIS • What are they? Verbs. • This is the “evolution” of the web • We have tried to force the web into the same mold as stand-alone programs • This is not good! • We need to take advantage of the asynchronous nature of web communication! 7

  8. REST • Definition: REST • Representation State Transfer • a software architectural style for distributed hypermedia systems, such as the web • (but not necessarily the web) 8

  9. Principles of REST • 1. Statelessness • In the simplest terms, this principle forbids for any state information to be stored on the server • This does not forbid state to be stored client-side • Every message though must contain all information needed for understanding 9

  10. Principles of REST • 2. Idempotency • The output of identical requests is itself identical • In other words, if you go to the same page twice, you get the same page (barring changes in the content model) • Allows for caching, which improves user-perceived responsiveness 10

  11. Principles of REST • 3. Addressable Resources • Everything has its place and every place has a thing • “Everything is a resource” • See amazon.com for a good example • URLs reflect the resource 11

  12. Principles of REST • 4. Well-defined operations • In the context of the Web and HTTP, we’re talking: • POST • GET • PUT • DELETE • This reflects possible actions 12

  13. Principles of REST • 5. Formatted/Structured Data • The resources you get should be encoded in a uniform way (like HTML, XML, etc.) 13

  14. Sounds good… but… • Sure sounds hard to pull off good web apps with these constraints… • Let’s think about a shopping application • What’s the “usual” way? 14

  15. RESTful Shopping • What are the actions that you want to take in a shopping application? 15

  16. RESTful Shopping • In real life, who holds the shopping cart? • You, or your personal shopping buddy provided by the store? • If it’s you (and I hope it is) where do you store cart information? • In a frame? (UGH… I just threw up a little in my mouth) • In a cookie? (not what it’s meant for!) • HTML5 SessionStorage object … eventually 16

  17. RESTful Shopping • Well, just for argument, we’ll give you your shopping buddy (we’ll call him “Carl”) • In this instance, the shopper will be asking the store to set aside items for them • The difference here is basically philosophical, but bear with me • If we treat the cart as part of the STORE and not owned by the CLIENT, then RESTfulness can still be maintained 17

  18. RESTful Shopping 18

  19. RESTful Shopping • Uh… wasn’t that a session? • Not quite – a session disappears when the user does • Theoretically, this would be around until the user removes everything or checks out • It is addressable, it’s formatted, it’s idempotent, and it uses defined operations • The differences are very subtle, but they are there 19

  20. Sounds good… but… • REST means that the server is stateless and cannot store any data about the client’s current state/session • This example was a bit extreme • Like most things, moderation is the key to getting the right balance between server and client resource utilization 20

  21. Your turn • Let’s go find some RESTful and non-RESTful apps. • Why are they behaving that way? • Why do you think they were designed this way? 21

  22. Review REST • REST: Representational State Transfer • It is a software architecture style / philosophy, not a protocol / system / etc. • Main Principles: • Stateless client-server – No state info is stored server-side • Identification of resources - Individual resources are identified in requests, for example using URIs • Manipulation of resources through a simplified set of operations – In HTTP, POST, GET, PUT, and DELETE • The use of structured data – Such as HTML or XML 22

  23. REST Examples • What web systems are RESTful? Others? • CS4720 homepage? Yes. • cnn.com? Potentially. • Collab? The architecture potentially, but not the individual modules. • SIS? Is there a rule it doesn’t break? • Remember the fundamental concept: nouns (resources), not verbs (actions) to interact 23

More Related