Post on 22-Mar-2016
description
INF 123 SW ARCH, DIST SYS & INTEROP
LECTURE 7Prof. 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
<link href="mystyle.css" rel="stylesheet" type="text/css” /> <img src=”mypic.gif" alt=”My Picture" /> Semantics: Embedded Retrieval GET
Anchors <a href=URI>Anchor text</a> Semantics: Potential Retrieval GET
Forms <form action=URI method=OP>
input fields</form>
Semantics: OP = Potential Retrieval GET | Potential Creation POST Scripts
<script type=“text/javascript”> script statements</script>
JavaScript has the capability of invoking HTTP operations on servers programmatically
Lecture 6 Web Application Architecture
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
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.
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<html> <head> <title>Test</title> </head> <body> <?php echo "Hello World”;?> </body></html>
#!/usr/local/bin/perl
print "Content-type: text/html\n\n"; print "<html>\n<head>";print "<title>Test</title>\n";print "</head>\n<body>\n";print "Hello, world!\n";print "</body>\n</html>";
helloworld.pl helloworld.php
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
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 s
tory!
Design Principle: Client-Server Components
Servers provide access to resources Clients access the resources via servers
Client ServerRequest
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/IPtagus: crista$ telnet smtp.ics.uci.edu 25Trying 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.edu250 david-tennant-v0.ics.uci.edu Hello barbara-wright.ics.uci.edu [128.195.1.137], pleased to meet youMAIL FROM:<lopes@ics.uci.edu>250 2.1.0 <lopes@ics.uci.edu>... Sender okRCPT TO:<lopes@ics.uci.edu>250 2.1.5 <lopes@ics.uci.edu>... Recipient okDATA354 Enter mail, end with "." on a line by itselftest.250 2.0.0 o360F1Mo029280 Message accepted for deliveryQUIT221 2.0.0 david-tennant-v0.ics.uci.edu closing connectionConnection closed by foreign host.
Stateful communica
tion
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 CacheRequest
ResponseServer
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 ElementsUniform 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
LoggedOut
CreateAccou
nt
LoggedIn
User
Change
Account
LoggedIn
Admin
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 nextLoggedOut
LoggedIn
User
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 LoggedOut
LoggedIn
User
Change
Account
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
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
HTTP Operations (recap) GET PUT DELETE HEAD OPTIONS TRACE POST CONNECT
Spec
Idempotent methodsMeans: the side effects of many invocations are exactly the same as the side effects of one invocation
See Wikipedia Idempotent
RESTful Design GuidelinesCanonicalexample
REST Design in Action (and not)
HATEOAS
Possible sta
te 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/<uuid> /admin/users /admin/users/edit/<uuid> /install /login /logout
Better:•/installation•/sessions
HTTP Ops Use Most ok, but…
(In useraccountform.html)
<p >Your Account:</p> <form action="/wifi/user/account/<!-- #get field=PrincipalID -->" method="POST"> <p class="bodytext"> Email:<br/> <input name="email" type="text" value="<!-- #get field=Email -->" class="inputstyle" /> <input type="submit" value="update" class="button" /> </p> </form>
State
namespace Diva.Wifi{ public class Services { … // Sessions private Dictionary<string, SessionInfo> m_Sessions = new Dictionary<string, SessionInfo>(); … }}
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