Removed REST chapter.
This commit is contained in:
Arjen Poutsma
parent
1f13148458
commit
a4419c98bf
|
|
@ -1,82 +0,0 @@
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
||||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
||||||
<chapter id="rest">
|
|
||||||
<title>REST support</title>
|
|
||||||
|
|
||||||
<section id="rest-introduction">
|
|
||||||
<title>Introduction</title>
|
|
||||||
|
|
||||||
<para>The goal of Spring's REST support is to make the development of
|
|
||||||
RESTful Web services and applications easier.</para>
|
|
||||||
|
|
||||||
<para>Client-side access to RESTful resources is greatly simplified using
|
|
||||||
Spring <classname>RestTemplate</classname>.
|
|
||||||
<classname>RestTemplate</classname> follows in the footsteps of other
|
|
||||||
template classes in Spring such as <classname>JdbcTemplate</classname> and
|
|
||||||
<classname>JmsTemplate</classname>. Instead of dealing with a verbose
|
|
||||||
lower level API such as Apache Commons <classname>HttpClient</classname>
|
|
||||||
to create RESTful request, RestTemplate provides one liner methods that
|
|
||||||
are purpose built for RESTful programming.</para>
|
|
||||||
|
|
||||||
<para>On the server-side, Spring's REST support is based upon Spring's
|
|
||||||
existing annotation based MVC framework. (For those interested in the
|
|
||||||
rational for that decision, and for not implementing JAX-RS, read Arjen
|
|
||||||
Poutsma's SpringSource TeamBlog <ulink
|
|
||||||
url="http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/">entry</ulink>.)
|
|
||||||
With little effort, you can marshall data out of a RESTful request using
|
|
||||||
<classname>@RequestMapping</classname> and
|
|
||||||
<classname>@PathVariable</classname> annotations and return different
|
|
||||||
views as determined by the request's <literal>Context-Type</literal>
|
|
||||||
header.</para>
|
|
||||||
|
|
||||||
<para>In this chapter we describe all the features of Spring's REST
|
|
||||||
support. It is divided into two main chapters, one for the server-side and
|
|
||||||
one for the client-side. For those new to Spring's <link linkend="mvc">MVC
|
|
||||||
framework</link>, you may want to read through the reference documentation
|
|
||||||
on <link linkend="mvc-annotation">annotation-based controller
|
|
||||||
configuration</link> to understand the general programming model.</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
|
|
||||||
<section id="rest-etag">
|
|
||||||
<title>ETag support</title>
|
|
||||||
|
|
||||||
<para>An <ulink
|
|
||||||
url="http://en.wikipedia.org/wiki/HTTP_ETag">ETag</ulink> (entity tag)
|
|
||||||
is an HTTP response header returned by an HTTP/1.1 compliant web server
|
|
||||||
used to determine change in content at a given URL. It can be considered
|
|
||||||
to be the more sophisticated successor to the
|
|
||||||
<literal>Last-Modified</literal> header. When a server returns a
|
|
||||||
representation with an ETag header, the client can use this header in
|
|
||||||
subsequent GETs, in an <literal>If-None-Match</literal> header. If the
|
|
||||||
content has not changed, the server will return <literal>304: Not
|
|
||||||
Modified</literal>.</para>
|
|
||||||
|
|
||||||
<para>Support for ETags is provided by the servlet filter
|
|
||||||
<classname>ShallowEtagHeaderFilter</classname>. Since it is a plain
|
|
||||||
Servlet Filter, and thus can be used in combination with any web
|
|
||||||
framework. The <classname>ShallowEtagHeaderFilter</classname> filter
|
|
||||||
creates so-called shallow ETags (as opposed to deep ETags, more about
|
|
||||||
that later). The way it works is quite simple: the filter simply caches
|
|
||||||
the content of the rendered JSP (or other content), generates an MD5
|
|
||||||
hash over that, and returns that as an ETag header in the response. The
|
|
||||||
next time a client sends a request for the same resource, it uses that
|
|
||||||
hash as the <literal>If-None-Match</literal> value. The filter notices
|
|
||||||
this, renders the view again, and compares the two hashes. If they are
|
|
||||||
equal, a <literal>304</literal> is returned. It is important to note
|
|
||||||
that this filter will not save processing power, as the view is still
|
|
||||||
rendered. The only thing it saves is bandwidth, as the rendered response
|
|
||||||
is not sent back over the wire.</para>
|
|
||||||
|
|
||||||
<para>Deep ETags are a bit more complicated. In this case, the ETag is
|
|
||||||
based on the underlying domain objects, RDMBS tables, etc. Using this
|
|
||||||
approach, no content is generated unless the underlying data has
|
|
||||||
changed. Unfortunately, implementing this approach in a generic way is
|
|
||||||
much more difficult than shallow ETags. Spring may provide support for
|
|
||||||
deep ETags in a later release by relying on JPA's @Version annotation,
|
|
||||||
or an AspectJ aspect.</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
|
|
||||||
</chapter>
|
|
||||||
|
|
@ -264,9 +264,6 @@
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><xref linkend="view"/></para>
|
<para><xref linkend="view"/></para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
|
||||||
<para><xref linkend="rest"/></para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><xref linkend="web-integration"/></para>
|
<para><xref linkend="web-integration"/></para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
@ -277,7 +274,6 @@
|
||||||
</partintro>
|
</partintro>
|
||||||
<xi:include href="mvc.xml"/>
|
<xi:include href="mvc.xml"/>
|
||||||
<xi:include href="view.xml"/>
|
<xi:include href="view.xml"/>
|
||||||
<xi:include href="rest.xml"/>
|
|
||||||
<xi:include href="web-integration.xml"/>
|
<xi:include href="web-integration.xml"/>
|
||||||
<xi:include href="portlet.xml"/>
|
<xi:include href="portlet.xml"/>
|
||||||
</part>
|
</part>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue