1. INF 123 SW ARCH, DIST SYS & INTEROP LECTURE 7 Prof. Crista Lopes

2. Objectives  Thorough understanding REST

3. Recap  HTTP  URLs  Methods  Headers  Status Codes  Caches  Cookies  HTML and HTTP  hrefs/imgs  Forms  Scripts (XMLHttpRequest)

4. HTML and HTTP  Links and images   Semantics: Embedded Retrieval  GET  Anchors  Anchor text  Semantics: Potential Retrieval  GET  Forms  input fields  Semantics: OP = Potential Retrieval  GET | Potential Creation  POST  Scripts  script statements  JavaScript has the capability of invoking HTTP operations on servers programmatically

5. Lecture 6  Web Application Architecture

6. First Web Programs  GET http://example.com/file.html  GET http://example.com/program.py?arg=3 (or POST)  Web server needs to recognize files extensions and react appropriately  Common Gateway Interface (CGI) model

7. First Web Programs – CGI  A standard (see RFC3875: CGI Version 1.1) that defines how web server software can delegate the generation of webpages to a console application.RFC3875: CGI Version 1.1  Console app can be written in any PL  CGI programs generate HTML responses  First CGI programs used Perl  1993

8. First Web Programs – PHP  Natural extension of CGI/Perl, 1994  Embedded scripting language that helped Perl Test #!/usr/local/bin/perl print "Content-type: text/html\n\n"; print " \n "; print " Test \n"; print " \n \n"; print "Hello, world!\n"; print " \n "; helloworld.pl helloworld.php

9. Web Programming  It all went down hill from here  1995-2000: a lot of bad programming styles  Generalized confusion about how to use HTTP  HTTP reduced to GET and POST  HTTP reduced to POST (!) in some models

10. REST  REpresentational State Transfer  Explanation of HTTP 1.1 (for the most part)  Style of writing distributed applications  “Story” that guides the evolution of Web standards  Formulated by 2000, Roy Fielding (UCI/ICS)

11. The importance of REST  Late-90’s HTTP seen as  just convenient mechanism  just browser clients  not good enough for server-server interactions  Ad-hoc use, generalized confusion  GET, POST, PUT … what’s the difference?  People started mapping other styles onto it  e.g. RPC, SOAP  HTTP got no respect/understanding until REST was formulated

12. HTTP vs. REST  REST is the conceptual story  HTTP is an enabler of REST on the Web  Not every use of HTTP is RESTful  REST can be realized with other network protocols  History lessons:  Realization (HTTP) came first, concepts (REST) became clear later  Good concepts are critically important

13. REST Design Principles  Client-server  Stateless  Caching  Layered  Code-on-demand  Uniform interface

14. Main Design Principles, originally  Client requests a text document from the server  Server sends back the text document  Text document may contain retrieval references (hyperlinks) to other text documents on that or other servers  HyperText Markup Language (HTML)  Client may also send text documents for the server to store  Requests/Responses sent over TCP, but  Client makes connection, sends, receives, connection is closed Connection is not maintained among interactions  Requests are self-contained, do not rely on past interactions “Stateless”  (Notice the story based on “text document”; it quickly became apparent that it needed generalization) Compare with this story!

15. Design Principle: Client-Server  Components  Servers provide access to resources  Clients access the resources via servers Client Server Request Response

16. Design Principle: Stateless  Stateless interaction, not stateless servers  Stateless interaction:  Messages are self-contained, every message from client to server is independent of prior messages Compare with SMTP  Server may create resources (e.g. session info) regarding clients  Critical for real applications  Preferably in DB  After serving, server does not “hold on”

17. Recap: SMTP over TCP/IP tagus: crista$ telnet smtp.ics.uci.edu 25 Trying 128.195.1.219... Connected to smtp.ics.uci.edu. Escape character is '^]'. 220 david-tennant-v0.ics.uci.edu ESMTP mailer ready at Mon, 5 Apr 2010 17:15:01 -0700' HELO smtp.ics.uci.edu 250 david-tennant-v0.ics.uci.edu Hello barbara-wright.ics.uci.edu [128.195.1.137], pleased to meet you MAIL FROM: 250 2.1.0... Sender ok RCPT TO: 250 2.1.5... Recipient ok DATA 354 Enter mail, end with "." on a line by itself test. 250 2.0.0 o360F1Mo029280 Message accepted for delivery QUIT 221 2.0.0 david-tennant-v0.ics.uci.edu closing connection Connection closed by foreign host. Stateful communication

18. Design Principle: Caching  REST embraces/encourages the existence of caches  Responses may explicitly state whether data is cacheable or not  Cacheable data can be reused without new requests to server Client Cache Request Response Server

19. Design Principle: Layered From Fielding’s dissertation

20. Design Principle: Code-on-Demand From Fielding’s dissertation

21. Design Principle: Uniform Interfaces  Uniform identification of resources  Manipulation of resources via representations  Hypermedia as engine of app state

22. REST Data Elements Uniform Interfaces

23. Resources and their identifiers  Resource = Abstraction of information, any information that can be named  A document, a temporal service (“today’s weather”), collection of other resources  Some are static, some are dynamic  Identifiers: Universal Resource Identifiers (URIs) Uniform Interfaces

24. Representations  Server returns representations of resources, not the resources themselves.  E.g. HTML, XML  Server response contains all metadata for client to interpret the representation Uniform Interfaces

25. HATEOAS  Hypermedia As The Engine Of Application State  Insight: the application is a state machine  Wifi example: Uniform Interfaces Logged Out Create Account Create Account Logged In User Logged In User Change Account Change Account Logged In Admin Logged In Admin Search Users Search Users … Question is: Where is the clients’ state stored?

26. HATEOAS  In many systems, clients’ state is kept on the server  Traditional way of engineering apps Server is both the state machine and the holder of state  In REST, state machine is on the server, but clients’ state is sent to the clients  At any step, client is sent a complete “picture” of where it can go next Logged Out Logged In User Logged In User Change Account Change Account

27. HATEOAS  Server sends representation of the client’s state back to the client  Hence, REpresentional State Transfer  Server does not “hold on” to client’s state  Possible next state transitions of the client are encoded in Hypermedia  Anchors, forms, scripted actions, eXternal reps Logged Out Logged In User Logged In User Change Account Change Account

28. RESTful Design Guidelines  Embrace hypermedia  Name your resources/features with URIs  Design your namespace carefully  Hide mechanisms  Bad: http://example.com/cgi-bin/users.pl?name=John  Good: http://example.com/users/John  Serve POST, GET, PUT, DELETE on those resources  Roughly, Create, Retrieve, Update, Delete (CRUD) life-cycle  Don’t hold on to state  Serve and forget (functional programming-y)  Consider serving multiple representations  HTML, XML

29. RESTful Design Guidelines  URIs are nouns  The 8 HTTP operations are verbs  Very different from CGI-inspired web programming!  Many/most web prog frameworks promote URIs as verbs and query data as nouns – old CGI model. https://eee.uci.edu/toolbox/dropbox/index.php?op=createdropboxform http://us.mc510.mail.yahoo.com/mc/welcome?.gx=1&.tm=1271634041&.rand=9anflcttvlh7n#_pg=showFolder&fid=Inbox&order=down&tt=237&pSize=100&.rand=952814729&.jsrand=4316826

30. HTTP Operations (recap)  GET  PUT  DELETE  HEAD  OPTIONS  TRACE  POST  CONNECT  Spec Spec Idempotent methods Means: the side effects of many invocations are exactly the same as the side effects of one invocation See Wikipedia IdempotentIdempotent

31. RESTful Design Guidelines Canonical example

32. REST Design in Action (and not)

33. HATEOAS Possible state transitions of current state LoggedInAdmin Hence, Hypermedia As The Engine Of Application State

34. State Machine & Encodings in Wifi public string GetContent(Environment env) { m_log.DebugFormat("[WifiScriptFace]: GetContent, flags {0}", env.Flags); if ((env.Flags & StateFlags.InstallForm) != 0) return m_WebApp.ReadFile(env, "installform.html"); if ((env.Flags & StateFlags.InstallFormResponse) != 0) return "Your Wifi has been installed. The administrator account is " + m_WebApp.AdminFirst + " " + m_WebApp.AdminLast; if ((env.Flags & StateFlags.FailedLogin) != 0) return "Login failed"; if ((env.Flags & StateFlags.SuccessfulLogin) != 0) return "Welcome to " + m_WebApp.GridName + "!”; if ((env.Flags & StateFlags.NewAccountForm) != 0) return m_WebApp.ReadFile(env, "newaccountform.html", env.Data); if ((env.Flags & StateFlags.NewAccountFormResponse) != 0) return "Your account has been created.”; … WifiScriptFace

35. URI Design – nouns?  /user/account  /user/account/  /admin/users  /admin/users/edit/  /install  /login  /logout Better: /installation /sessions

36. HTTP Ops Use  Most ok, but… (In useraccountform.html) Your Account: " method="POST"> Email: " class="inputstyle" />

37. State namespace Diva.Wifi { public class Services { … // Sessions private Dictionary m_Sessions = new Dictionary (); … } This does not scale!

38. The Reality of Software Architecture  Know what “good” means, strive for being good  If you need to be bad  Do it consciously  Have a good reason  Know how to fix it

39. REST, back to the beginning  REpresentational State Transfer  Now you really know what this means!  Explanation of HTTP 1.1 (for the most part)  Much needed conceptual model  Style of writing distributed applications  Design guidelines  “Story” that guides the evolution of Web standards  A lighthouse for new ideas