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

Objectives  Thorough understanding REST

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

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

Lecture 6  Web Application Architecture

First Web Programs  GET  GET (or POST)  Web server needs to recognize files extensions and react appropriately  Common Gateway Interface (CGI) model

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

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

Web Programming  It all went down hill from here  : 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

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)

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

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

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

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!

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

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”

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

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

Design Principle: Layered From Fielding’s dissertation

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

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

REST Data Elements Uniform Interfaces

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

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

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?

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

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

RESTful Design Guidelines  Embrace hypermedia  Name your resources/features with URIs  Design your namespace carefully  Hide mechanisms  Bad:  Good:  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

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.

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

RESTful Design Guidelines Canonical example

REST Design in Action (and not)

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

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

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

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

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

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

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