13. Java
HTML
ipt
JavaScr
S
CS
Current
JSP
Browser
14. Current
JavaScr
Browser
HTML
Java
ipt
CS
JSP
HTML page S
15. Java
Current
String hql = "from Person p where p.age > :age";
Query q = session.createQuery();
q.setInteger("age", 33);
List people = q.list(hql);
JavaScr
Browser
HTML
Java
JSP
ipt
CS
<table>
JSP
S
<% for (Person p : people) { %>
<tr>
<td>p.getName()</td>
<td>p.getAge()</td>
</tr>
<% } %>
</table>
16. JSP
<%
Current
if (request.getParameter("age") != null) {
age=Integer.parseInt(request.getParameter(“age”));
}
JavaScr
Browser
String hql = "from Person p where p.age > :age";
HTML
Java
Query q = session.createQuery();
q.setInteger("age", age);
List people = q.list(hql);
ipt
CS
%>
JSP
S
<table>
<% for (Person p : people) { %>
<tr>
<td>p.getName()</td>
<td>p.getAge()</td>
</tr>
<% } %>
</table>
17. JavaScript
Current
var onClick = function () {
$.ajax({
url: ‘/people/’,
dataType: ‘json’,
JavaScr
Browser
data: { age: 33 },
success: function (data) {
HTML
Java
var rows = [];
$.each(data, function (person) {
rows.push(‘<tr><td>’ + person.name +
ipt
CS
‘</td><td>’ + person.age +‘</td></tr>’);
JSP
S
}
$(‘#peopletable > tbody:last’).append(
‘’.join(rows));
}
}
32. Pros
• browsers
• mobile devices
• programmatic clients
• HTTP
• Accessible API
33. Pros
• can have several
different server
• Accessible API
implementations
• same UI can be placed
• Reusable API
“on top” of another
server implementation
as long as it is the same
API
• no predefined
application flow
34. Pros
• Accessible API • responsibilities are
easier to assign
• Reusable API • data validation
• error handling
• Decoupling • localization
35. Pros
• Accessible API • unambiguously assign
responsibilities for state
• Reusable API
handling
• server is responsible
• Decoupling
for resources and their
states
• Application flow / state • application (client) is
responsible for the
application flow and
state
36. Pros
• Accessible API • fewer technologies to
worry about
• Reusable API • one language for the
client
• Decoupling • one language (maybe
even the same) for the
• Application flow / state
server
• client and server are
• Development model easier to develop in
parallel
37. Pros
• Accessible API
• Reusable API • client and server may
be tested separately
• Decoupling • server API may be
tested using isolated
• Application flow / state
HTTP request and
checking the result
• Development model
codes and content
• UI may be tested
• Testing
without the server or
the network traffic
38. Pros
• Accessible API
• Reusable API • REST offers minimal
HTTP overhead
• Decoupling • network is utilized
only when necessary
• Application flow / state
(no page reloads)
• no data (e.g. HTML or
• Development model
CSS) overhead when
transferring only payload
• Testing
data (e.g. JSON or XML)
• Network traffic
39. Cons
• some server
frameworks have REST
support
• MVC support on
• Framework support
client depends solely on
the chosen toolkit
40. Cons
• single page web
applications are difficult
• Framework support
to crawl and index
• RESTful API could be
• Search engine support
crawled and indexed but
difficult to rank
41. Cons
• highly dynamic
JavaScript UIs require
• Framework support
extra work to be
accessible for the
• Search engine support
visually impaired
• some JavaScript
• Accessibility
toolkits offer support
for accessibility
42. Future work
• Authentication
• Flexible authorization configuration
• per resource
• per request method
• representations per auth level?