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>
|
||||
<para><xref linkend="view"/></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><xref linkend="rest"/></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><xref linkend="web-integration"/></para>
|
||||
</listitem>
|
||||
|
|
@ -277,7 +274,6 @@
|
|||
</partintro>
|
||||
<xi:include href="mvc.xml"/>
|
||||
<xi:include href="view.xml"/>
|
||||
<xi:include href="rest.xml"/>
|
||||
<xi:include href="web-integration.xml"/>
|
||||
<xi:include href="portlet.xml"/>
|
||||
</part>
|
||||
|
|
|
|||
Loading…
Reference in New Issue