INF_123_Lecture_7
advertisement
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
Anchors
<a href=URI>Anchor text</a>
Semantics: Potential Retrieval GET
Forms
<link href="mystyle.css" rel="stylesheet" type="text/css” />
<img src=”mypic.gif" alt=”My Picture" />
Semantics: Embedded Retrieval GET
<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
#!/usr/local/bin/perl
print
print
print
print
print
print
"Content-type: text/html\n\n";
"<html>\n<head>";
"<title>Test</title>\n";
"</head>\n<body>\n";
"Hello, world!\n";
"</body>\n</html>";
helloworld.pl
<html>
<head>
<title>Test</title>
</head>
<body>
<?php echo "Hello World”;?>
</body>
</html>
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
People started mapping other styles onto it
GET, POST, PUT … what’s the difference?
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
Text document may contain retrieval references (hyperlinks) to other text
documents on that or other servers
Server sends back the text document
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
Requests are self-contained, do not rely on past interactions
Connection is not maintained among interactions
“Stateless”
(Notice the story based on “text document”; it quickly became apparent
that it needed generalization)
Design Principle: Client-Server
Components
Servers
provide access to resources
Clients access the resources via servers
Request
Server
Client
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 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
MAIL FROM:<lopes@ics.uci.edu>
250 2.1.0 <lopes@ics.uci.edu>... Sender ok
RCPT TO:<lopes@ics.uci.edu>
250 2.1.5 <lopes@ics.uci.edu>... 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.
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
Request
Client
Cache
Server
Response
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
Uniform Interfaces
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:
Create
Account
Question is:
Where is the clients’ state stored?
Logged
Out
Logged
In
User
Change
Account
Logged
In
Admin
Search
Users
…
HATEOAS
In many systems, clients’ state is kept on the server
Traditional
Server
way of engineering apps
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
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
Change
Account
RESTful Design Guidelines
Embrace hypermedia
Hide mechanisms
Roughly, Create, Retrieve, Update, Delete (CRUD) life-cycle
Don’t hold on to state
Bad: http://example.com/cgi-bin/users.pl?name=John
Good: http://example.com/users/John
Serve POST, GET, PUT, DELETE on those resources
Name your resources/features with URIs
Design your namespace carefully
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!
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
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
Idempotent methods
Means: the side effects of many invocations are
exactly the same as the side effects of one
invocation
See Wikipedia Idempotent
RESTful Design Guidelines
Canonical
example
REST Design in Action (and not)
HATEOAS
Hence, Hypermedia As The Engine Of Application State
State Machine & Encodings in Wifi
WifiScriptFace
public string GetContent(Environment env)
{
m_log.DebugFormat("[WifiScriptFace]: GetContent, flags {0}", e
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 ac
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.D
if ((env.Flags & StateFlags.NewAccountFormResponse) != 0)
return "Your account has been created.”;
…
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="inputstyl
<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
Explanation of HTTP 1.1 (for the most part)
Much
you really know what this means!
needed conceptual model
Style of writing distributed applications
Design
guidelines
“Story” that guides the evolution of Web standards
A
lighthouse for new ideas
