Slides

crashclappergapSoftware and s/w Development

Dec 13, 2013 (3 years and 7 months ago)

70 views

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


<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


RE
presentational

S
tate
T
ransfer


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)


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 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:<
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

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


H
ypermedia
A
s
T
he
E
ngine
O
f
A
pplication
S
tate


Insight: the application is a state machine


Wifi

example:

Uniform Interfaces

Logged
Out

Create

Account

Logged

In

User

Change

Account

Logged

In

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 next

Logged
Out

Logged

In

User

Change

Account

HATEOAS


Server sends
representation of the client’s state

back to the client


Hence,
RE
presentional

S
tate
T
ransfer


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


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 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


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


RE
presentational

S
tate
T
ransfer


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