Spring Framework

References:
Pro Spring, Fourth Edition
By: Chris Schaefer; Clarence Ho; Rob Harrop
Spring Documentation
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/
 Overview
● Lightweight framework for building Java applications
● Can be used to build any kind of application from standalone Java application to web
based to enterprise application.
● Modular, so one can use only the needed modules.
● Non-intrusive, domain logic does not have dependencies on the framework. Data
access has some dependencies on the framework but can be limited to the same
layer and domain logic can be delinked.
● Lets you work with PoJo's and adds the framework support non-invasively.
 Overview
● Provides enterprise infrastructure services (as APIs) to POJOs without having to
deal with the plumbing code (there are many services like messaging, database
access, security, REST, MVC etc. checkout https://spring.io/projects)
● Allows class dependencies to be injected using annotations which make classes self
documenting and dependencies are explicit (more readable code)
● Enables laying out specific behaviors on the class with simple annotations like
transactions (AOP)
 Overview - Evolution
● Spring 0.9
The first public release of the framework, based on the book Expert One-on-One:
J2EE Design and Development by Rod Johnson (2002)
● Spring 1.x
● Spring Core: Bean container

● Spring context: Application context

● Spring ORM: Hibernate, iBATIS, JDO support

● Spring DAO, Spring AOP, Spring Web and Spring MVC

● Spring 2.0
● Easy XML based configuration

● JPA support

● Java 5 support

● Spring 2.5
● Introduction @Autowired

● New stereo type annotations @Component, @Service, @Controller, @Repository

● Auto scanning and wiring of classes with stereotype annotations

● Spring Test Framework

● Spring 3.0
● Spring Expression Language

● REST support

● Java based configuration

● Support for embedded database like h2, hsql and derby

● Spring 4.x
 Overview - Evolution
● Supports Java 8 (lambdas for call back etc), min JDK 6
● Servlet 3.0 spec is highly recommended and considered minimum for most of the
features. Similarly JPA 2.0 is the minimum requirement on the deployment platform.
● Support added for Java EE7 applications spec e.g. JPA 2.1, JMS 2.0 etc.
● Bean configuration now possible via Groovy DSL. This is similar to XML based
configuration but is more concise.
● There is more what wont make much sense to me as I am new to the framework.
Following link has details.
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-wha
ts-new.html
Overview
 Overview
● Core Container
● spring-core and spring-beans

provide the dependency injection / IoC container. Allows a class to easily configure
and specify the dependencies that it needs. So that class focuses on actual logic.
● spring-context

provides access to the objects. Its used via the ApplicationContext interface.
● spring-expression

provides an expression language to access/manipulate object graph in run time.

Can be used to set/get object properties, method invocation etc.
● AOP
spring-aop module allows you to specify behavioral/aspect information in the code.
For example declarative transaction management which cuts across multiple
objects. You can define custom aspects. spring-aspects module integrates with
AspectJ and spring-instrument provides class instrumentation support.
● Messaging
spring-messaging simplifies adding support for messaging into your application.
Allows mapping methods to messages using annotations.
●
 Overview
● Data Access / Integration
● spring-jdbc provides an abstraction over JDBC to access database

● spring-tx provides support for declarative transaction management

● spring-orm provides integration layers for object/relational mapping frameworks

like JPA, JDO, Hibernate.

● spring-oxm provides abstraction layer for using object to xml mapping (and vice

versa) with many frameworks like Castor, Xstream, JAXB etc.

● spring-jms supports sending and receiving messages. Since 4.1, its integrated

with spring-messaging.
● Web
● spring-web provides multipart file upload, initialization of IoC container from web

app context and servlet listeners.

● spring-webmvc is the spring's MVC implementation.

● spring-webmvc-portlet provides MVC implementation for the portlet environment.

● Test
spring-test module provides support for unit testing using junit and testng. Allows
loading of application context. Provides mock objects for testing the code in isolation.

Portlet is a pluggable UI component. A web portal is collection of such portlets

where each portlet takes care of a particular window. For example mail client.
 Why Spring?
● Very active community
● Good documentation
● Fast pace development for new features
● Inbuilt testing framework to support TDD
● Excellent IDE tool (STS) for faster development
● Spring author Rod Johnson became part of the JSR 330 which was for
dependency injection support in Java.
 Spring vs J2EE

Refer: http://www.slideshare.net/kelapure/java-e-evsspringshootout
http://www.slideshare.net/kelapure/java-e-evsspringshootout
 Spring vs J2EE (2012)

Refer: http://www.slideshare.net/reza_rahman/java-ee-and-spring-sidebyside-34320697
 Maven Integration
● Maven Basics
Maven is a tool for managing the build and dependencies of a project from a single
config file. Creating a maven project gives you the basic skeleton of the project. Use
the quick start archetype.
● Archtype is a maven plugin that contains various goals like 'generate' to perform
this task of creating a project. It allows users to create projects using a standard
template.
● Maven has a huge collection of plugins, e.g. jboss-maven-plugin.
● http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
● Maven downloads the artifacts (dependencies) and maintains in local repository
● pom.xml is the file that contains the maven project information. POM stands for
project object model.
∘ modelVersion specify the version of object model. we use 4.0.0.
● Maven build lifecycle has many phases like clean, validate, compile, test, package,
integration-test, install, deploy. When a particular phase is given then maven runs all
the prior phases upto specified phase. 'site' phase generates the documentation for
the project.
● Bill of Materials (BOM) dependency allows specifying the version at one place. All
direct/transitive dependencies are automatically pulled based on the BOM version to
avoid any compatibility issues. Spring also provides a bom dependency spring-
framework-bom.
 Maven Integration
● The Maven Central repository (by Apache) is used by Spring and many other open
source softwares to publish their libraries. This is the default repository that maven
automatically searches for dependencies.
● Dependency Scope
● Compile (default) – these dependencies are available all the time in compile, run

time and test class path

● Runtime – only during run time and test phase but not compile

● Provided – do not add the dependency in the jar/war as its provided by the

environment only use it for compile time (for example servlet.jar)

● Test – only during test phase

● System – similar to provided scope but the dependency is expected on the system

and not pulled from repository

● Import – applicable to pom.xml type dependencies and indicates that these are

replaced with the dependencies in the target pom.xml

 Gradle Integration
● ss
 Logging
● Spring library has a dependency on Apache common-logging
● common-logging allows any library to be independent of the logging framework used
by the application. It has a run time discovery algorithm for detecting logging libraries
in the class path
● SLF4J (Simple logging facade for Java) is also similar and seems to be now a
preferred choice because
● Its more efficient. It uses compile time binding to the logging framework instead of

run time.
● Includes bridges to direct calls from existing logging frameworks to SLF4J which in

turn would route the requests to configured logging framework. This way you can
maintain dependencies at a single place.
● Logging performance is better as it uses parameterized logging.

●
 Dependency Injection
● A class should not instantiate its dependencies but rather let those be passed in via
constructor, factory method arguments or setters. This is called dependency
injection.
● Use an interface to represent a dependency so that a different implementation of
dependency can be injected.
● However these dependencies then need to be created by the caller.
● This problem is solved by the Dependency Injection Container (DIC) or Inversion of
Control (IoC container).
● The container lets you specify the way to create the dependencies and then every
one can get those by simple factory calls. Container managed objects are called
bean. In Spring you can define beans using XML, Java configuration, Annotations,
Groovy Bean Definition (4.x).
● In Spring, the ApplicationContext lets you access the dependencies or beans.
● Its called as inversion of control because instead of the class that uses
dependencies creating those, the dependencies are injected by the container into
the class.
● A container in simple terms is just a map that has a mapping of all the
dependencies/beans and the logic to create those beans. If a bean is already
created then its simply returned to the caller (singleton) otherwise a new one is
created and returned.
● Spring provides the DI container in a very non invasive way. You just need to follow
the basic Java Beans standard (getter/setter) for the dependencies.
 Dependency Injection
Benefits
● More testable code
● Easy to replace dependencies with mock objects

● Good application design

● Write against interfaces so its easy to change the implementation

● Loosely coupled components

● No boiler plate code

● Initializing dependencies need not be done at multiple places but just in the DI

code
● The dependent classes also become more clean

● All dependency configuration is centralized

● More readable code as dependencies are explicit for each component

Drawbacks
● Difficult to understand if the person is not familiar with the DI concepts
 Inversion of Control
Two types dependency injection and dependency look up.
● Dependency Injection (dependencies are injected, modern approach, easy)
Constructor or setter based initialization
● Dependency Lookup (components look for their dependencies, traditional approach)
Dependency pull and contextualized dependency lookup (CDL)
Inversion of Control – Dependency Pull

● Spring provides this via context.getBean() API.

● EJB 2.1 or prior was based on dependency pull.
 Inversion of Control – CDL

● Contextual Dependency Pull

● No registry is used, dependencies are directly pulled from the container
● Dependent object provides a lookup() API which container calls once dependencies
are ready. At this point, dependent object can start pulling the dependencies.
 Inversion of Control - DI
● Constructor based dependency injection
● Used when dependencies are mandatory for the creation of object

● Useful for Immutable classes (no setters allowed)

● Setter based dependency injection

● Used when dependent object has defaults for the optional dependencies

● Most commonly used DI

● Least intrusive

● There are container specific ways to mandate dependencies in this case as well

but that ties your code to container

● The setters need not be added to the business interface that dependent class

implements.
● Business interface should contain only those setters which are required by all

implementers.
● DI is better than lookup
● Simple, less code to write (no code to pull dependencies)

● Non intrusive (no need to implement any interface for dependency pull)

● Easy to test (dependencies can be replaced with mocks easily)

● Spring Bean Factory container injects the dependencies but the main method which
initializes the container needs to pull the dependencies via ApplicationContext. For
Spring MVC this is not needed and ContextLoaderListener is used.
 Bean Factory
● Core DI interface
● Manages the beans, their dependencies and life cycle
● Used to access the beans from the container
● Application must create an instance of a class that implements this interface. It also
require configuration of the class along with dependency information.
● Typically a class would implement BeanDefinitionReader along with BeanFactory.
This allows class to read bean configuration and load in BeanDefinition.
● There are two bean definition readers, PropertyBeanDefinitionReader and
XMLBeanDefinitionReader.
● Every bean has a name or id or both. This is used to refer them while specifying
dependencies and also while pulling them from the BeanFactory.
● DefaultListableBeanFactory is one of the default implementation of BeanFactory
interface and can be used to access beans.
 Application Context
● Extension to the BeanFactory interface. Provides additional services like transaction,
AOP, i18n, application event handling apart from accessing beans
● Need to be initialized manually in an application, for web application automatically
initialized via the ContextLoaderListener (in web.xml).Recommended way to interact
with Spring container.
● Many ways to set this up
● XML File

● Keeps the dependency configuration centralized.

The xml file need to declare the namespace for beans, There are othe spring
namespaces for aop, context for Application context configuration, tx for
transaction support.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
</beans>
● Annotation Based
● Gives developers a clear view of the configuration while working on the code.

Use the component scan tag:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd">
<context:component-scan base-package="com.apress.prospring4.ch3.annotation" />
</beans>
 Application Context
The <context:component-scan> tag tells Spring to scan the code for injectable beans
annotated with @Component, @Controller, @Repository, and @Service as well as
supporting the @Autowired and @Inject annotations under the package.

component scan tag can be configured to include/exclude some specific class based
on various criteria like class type, annotation type or some custom criteria as well.
● Mixed mode
● Infrastructure can be defined in XML and the bean config/dependencies via

annotations.
 Setter Injection
● Use the Property tag inside Bean tag:
<bean id="messageRenderer"
class="com.apress.prospring4.ch3.xml.StandardOutMessageRenderer">
<property name="messageProvider" ref="messageProvider"/>
</bean>
● Use the 'p' namespace and p attribute inside Bean tag
<bean id="messageRenderer"
class="com.apress.prospring4.ch3.xml.StandardOutMessageRenderer"
p:messageProvider-ref="messageProvider"/>
● Do not mix both styles (p namespace and property).
● Using annotations
● Add @Autowired annotation to the setter.
 Constructor Injection
● Define constructor to accept the dependencies as arguments.
● XML based
<bean id="messageProvider"
class="com.apress.prospring4.ch3.xml.ConfigurableMessageProvider">
<constructor-arg value="Configurable message"/>
</bean>
There is a 'c' based namespace as well to define the constructor arg.
● Annotation based
Use @Autowired annotation on the constructor along with @Value for the parameter.
For example:
@Autowired
public MyConstructor(@Value(“Hello”) String value) {}
● There is a way to specify the argument value in the xml file for annotation based
configuration as well. This is better than hardcoding values in the code.
<context:component-scan base-package="com.novell.test.springxmlconfig"></context:component-scan>
<bean id="message" class="java.lang.String" c:_0="hello from annotation with xml based string
bean"></bean>
● </context>
● Constructor confusion can happen if same number of arguments are there in two
constructors. In this case the argument type must specified in the xml or annotation
style injection should be used.
● Only one constructor can be marked with @Autowired.
 Injecting Parameters
● Using the 'p' name space, different types of parameters can be injected in the XML
file. Alternatively property tag can be used. Do not mix both styles. The basic types
are automatically converted appropriately.
<bean id="injectSimple" class="com.apress.prospring4.ch3.xml.InjectSimple"
p:name="Chris Schaefer" p:age="32" p:height="1.778" p:programmer="true"
p:ageInSeconds="1009843200"/>
● Spring provides @Value annotation to inject the default values.
@Value(“5.66”) //float value
● Values can be injected using SpEL as well. Spring expression language allows
access beans properties and injecting in other beans. For example:
<bean id="injectSimple" class="com.apress.prospring4.ch3.xml.InjectSimple"
p:name=”#{config.name}” p:age="#{config.age + 1}" p:height="#{config.height}"
p:programmer="#{config.programer}"
p:ageInSeconds="#{config.ageInSeconds}"/>

Here “config” is a bean which is defined in the xml file and has default values for
various properties. We have also manipulated the age by incrementing it by 1 before
injecting it. This can be also injected using annotation e.g. @Value(“#{config.age}”).
 Injecting Beans
● To inject a bean into another bean using XML, use the <ref> tag:
<bean id="oracle" name="wiseworm" class="com.apress.prospring4.ch3.BookwormOracle"/>
<bean id="injectRef" class="com.apress.prospring4.ch3.xml.InjectRef">
<property name="oracle">
<ref bean="oracle"/>
</property>
</bean>

● Nesting of Application Contexts. For large projects, its needed to have separate xml
files. One can refer to beans across application contexts (both parent and child). If
the same name bean is defined in both xml files then special mechanism needs to
be used to refer to the parent bean. Also, the child application context needs to set
the parent application context explicitly by calling
setParent(parentApplicationContext).
● You can also inject collections into the beans. There are XML tags defined for set,
map, props (properties) and list. Properties only allows Strings to be used as per
Java conventions.
● For annotations, use @Resource annotation to inject collections. To externalize the
collection elements, use util namespace in the XML file
● @Autowired does not work for collection injection as it will try to inject all beans of
the collection type (Employee in case of 'List<Employee>') instead of the appropriate
<util:list> bean.
 Method Injection
● If two collaborative beans have different life cycles then use Lookup method
injection. For example, the dependent bean is singleton while the dependency is
not singleton. In this case, every time a getter is called on the dependency a new
instance of dependency is given. The dependency bean scope has to be changed to
'prototype' instead of default (which is singleton).
● Spring provides a mechanism to replace the implementation of a particular bean
method with a different implementation. Use MethodReplacer interface for this. This
works using runtime byte code enhancement.
●
 Bean Naming
● There are various ways to name a bean
● Use “id” attribute

● Use “name” attribute

● Automatic naming (by default class name is used)

● Use of “id” attribute is recommended and more standard.

● The “id” must be unique for a given ApplicationContext.
● You can define multiple aliases for a bean by using the “name” attribute and
providing a space/comma/semicolon separated list of names. You can also use
<alias> tag for this.
● To obtain the bean, simply use the ApplicationContext.getBean(String) method
and provide the alias name.
● To obtain a list of aliases, use ApplicationContext.getAliases(String) and provide
one of the alias. This will give the remaining aliases as a list.
● Aliasing is useful while moving from one implementation of an interface from another
while there are existing beans defined using both implementations. In this case, the
bean with outdated implementation can be removed and the target bean can have a
alias name similar to earlier bean to take care of any references to old
implementation.
 Bean Instantiation Scope
● All beans in Spring are by default singletons. Every call to
ApplicationContext.getBean() returns same object.
● This is different from Singleton design pattern that ensure single instance but
couples the caller to the implementation. This makes it difficult to change the
implementation later. This also makes unit testing difficult as changing the singleton
with a mock object is not feasible.
● Using the “scope” attribute on the bean, one can change the bean life cycle as
below. This does not require any code changes in application unless you depend on
life cycle of bean:
● Singleton: The default singleton scope. Only one object will be created per Spring
IoC container.
● Prototype: A new instance will be created by Spring when requested by the
application.
● Request: For web application use. When using Spring MVC for web applications,
beans with request scope will be instantiated for every HTTP request and then
destroyed when the request is completed.
● Session: For web application use. When using Spring MVC for web applications,
beans with session scope will be instantiated for every HTTP session and then
destroyed when the session is over.
● Global session: For portlet-based web applications. The global session scope
beans can be shared among all portlets within the same Spring MVC–powered
portal application.
More.........
 Which Bean Scope?
● Thread: A new bean instance will be created by Spring when requested by a new
thread, while for the same thread, the same bean instance will be returned. Note that
this scope is not registered by default.
● Custom: Custom bean scope that can be created by implementing the interface
org.springframework.beans.factory.config.Scope and registering the custom scope in
Spring’s configuration (for XML, use the class
org.springframework.beans.factory.config.CustomScopeConfigurer).

● Use singleton scope, when

● Object is shared and has no state

● Object is shared and has read only state

● Object is shared and has shared state (ensure synchronization is granular)

● Object has limited writable state (but creating new instance is expensive, better

performance, ensure synchronization is granular).

● Use non singleton scope, when
● Object has lot of writable state (in this case cost of synchronization is more than

cost of creating new instances)

● Objects with private state
 Resolving Dependencies
● Spring instantiates beans in the order based on the dependencies among beans.
● This is important so that a bean is only initialized once all of its dependencies are
initialized.
● Spring cannot find dependencies which are created in the code. For example,
is some constructor/method, internally obtains a bean by calling
ApplicationContext.getBean(). This would not be detected by Spring and can lead to
problems.
● In such cases, use “depends-on” attribute while defining a bean that has some
coded dependencies which is not explicit.
● However avoid such situations by explicitly requesting dependencies via
constructor or setter injection.
 Autowiring Beans
● Normally when we create beans in the xml file, we also specify all its dependencies
explicitly. However Spring provides a way to automatically wire/configure a bean's
dependencies based on some fixed rules like name of the dependent bean or its
type. There are total 4 modes of autowiring: byName (setter injection), byType
(setter injection), constructor (by type), default.

● This is by default disabled and not recommended. Its better to wire the
necessary dependencies of the bean explicitly in the xml or its configuration class.
 Bean Inheritance
● There are times when you need to define multiple beans of the same type / interface.
The beans will have common properties, some of which individual beans might want
to customize. Typically one might copy paste the common properties across bean
definitions which is not a good idea and is difficult to maintain / error prone.

● Spring allows parent child relation between beans of similar type (same class /
interface hierarchy) in the same ApplicationContext.. Child bean will inherit
properties / constructor values from the parent and can optionally override any value
as needed.

● For this, set 'parent' property in the child bean definition appropriately.

● For example:
<bean id="inheritParent" class="com.apress.prospring4.ch3.xml.SimpleBean"
p:name="Chris Schaefer" p:age="32"/>

<bean id="inheritChild" class="com.apress.prospring4.ch3.xml.SimpleBean"

parent="inheritParent" p:age="33"/>
Spring Configuration
 Bean Life Cycle
● You can hook into either during bean creation (post creation) or during destruction.
For beans with prototype scope, you cannot hook into the destruction phase.
● Various Approaches to get to know about bean start/stop

● Interface based
● Implement InitializingBean to be notified about bean init

● Implement DisposableBean to be notified about bean destruction

● Method / XML based - avoids coupling the code with Spring framework
● Specify the method for creation and destruction in the bean configuration

● Annotation based – avoids coupling the code with Spring framework

Annotate the method with below annotations.
● @PostConstruct – for init

● @PreDestroty – for destroy

Note: To enable annotations, we need to add the <context:annotation-driven> tag from

the context namespace into the configuration XML file

● These hooks can be useful if certain default dependencies have to be loaded if no

other dependency has been provided by the user. It can also be used to trigger
some scheduled actions. Similarly, the pre destruction hooks help in cleanup /
flushing data before shutdown. Pre destructions hooks will only trigger if
registerShutdownHook() has been invoked on the application context or you
manually invoke context.destroy() API (on application context).
Bean Life Cycle
 BeanNameAware Interface
● A bean can implement this interface to get the name associated with it. This interface
has only one method setBeanName(String beanName) which is called by the Spring
container during initialization.

● A bean can use this name while logging messages to help in debugging. This
however ties your beans to Spring framework.
 ApplicationContextAware Interface
● A bean can implement this interface to get the ApplicationContext associated with it.
This interface has only one method setApplicationContext(ApplicationContext ctx)
which is called by the Spring container during initialization.

● A bean can use this context to pull other beans or register shutdown hook.
● This is typically needed for stand-alone Spring applications. For Spring MVC,
application context is automatically made available to the beans.
 FactoryBean Interface
● There are times when a particular dependency cannot be instantiated using the new
operator. These dependencies cannot be managed by the IoC container.
● The FactoryBean interface comes to rescue in such situations. It can act as an
adapter between the dependency and Spring's IoC container.
● Implement this interface in an adapter class to create the dependency (with
dependency specific factory / no new operator) and make it available to other beans
using regular dependency injection provided by Spring.
● To access the FactoryBean using application context, put an ampersand (&) before
the bean name. No reason to use this in application normally.
● Similar behavior can be achieved by using <bean> element's factory-bean and
factory-method attributes.
 PropertyEditor Interface
● Property editors are used to convert bean properties from String type to actual
Property type. These are part of Standard Java package java.beans.

● In BeanFactory configuration XML, all properties are defined as Strings but the
actual property value is not String. Spring uses custom property editors to convert
these values to actual property type.

● Spring has 13 custom property handlers for Date, Float, Boolean, File, Url, String,
Collection (List), InputStream, Locale, Pattern, ByteArray, Properties, Class. These
are automatically used by Spring depending on the type of property.

● To define a customer property editor for your own type, extend

PropertyEditorSupport class.
 More ApplicationContext Features
● Apart from BeanFactory related features, managing the bean life cycle, application
context provides additional features:
● I18n – Spring provides MessageSource interface for this. There are three

implementations StaticMessageSource (not recommended, cannot be configured

externally), ResourceBundleMessageSource (commonly used, leverages Java
ResourceBundle) and ReloadableResourceBundleMessageSource (additionally
can be refreshed to get new properties).
● ApplicationContext makes it easy to work with MessageSource. Just define a
MessageSource bean in your application and configure it with the message file
base names. After this you can call applicationContext.getMessage() to get the
localized message.
● It is NOT recommended to use ApplicationContext for this scenario as it ties your

bean to Spring framework. Use this if you are using Spring MVC framework as that
automatically loads ApplicationContext.

● For standalone applications, do not use ApplicationContext to access

MessageSource and instead inject MessageSource directly to your beans.
● MessageSourceResolvable interface can be implemented by an class to allow
searching inside MessageSource with its (MessageSourceResolvable) objects
(instead of key). This is typically used in Spring validation libraries to link Error
messages to corresponding i18ned messages.
 More ApplicationContext Features
Application Events
● Another feature of ApplicationContext is to allow publishing/receiving of events
among the beans.
● To listen for events, a bean needs to implement the ApplicationEvent interface.
● Event object needs to extend the MessageEvent class.
● To publish events, use applicationContext.publishEvent() API.

Use Cases
● Using events help decouple components. If a database update component needs to
inform the caching component about the changes then one way would for database
component to call the update() API on caching component. However this would
couple database component with caching component. If tomorrow we need to
remove caching then it would require changing the update component as well.
Similarly if some other component is also interested in the database updates then
again we need to modify the database update component.
● The better approach would be to use Spring's event mechanism and let database
update component publish an update event. The caching component can register as
a listener for that event and take action.
● One can also use JMS/Messaging technology for this. However typically these are
used for long running business critical applications. Also for distributed applications
scenario these can be used.
 More ApplicationContext Features
Accessing Resources
● Spring provides a Resource interface to access resources from file
system(FileSystemResource), classpath (ClassPathResource) and url
(UrlResource).

● Use applicationContext.getResource() API. For example:

● Ctx.getResource(“file://home/mneeraj/test.txt”);

● Ctx.getResource(“classpath:test.txt”);

● Ctx.getResource(“http://www.google.com”);

● The Resource interface has many methods to get the resource information like
getDescription(), contentLength(), exists(), getInputStream(), getFileName(),
getURI(), isReadable() etc.

● Recommended to use getInputStream() as this works across all file system,

classpath and url resources.
 More ApplicationContext Features
Accessing Resources
● Spring provides a Resource interface to access resources from file
system(FileSystemResource), classpath (ClassPathResource) and url
(UrlResource).

● Use applicationContext.getResource() API. For example:

● Ctx.getResource(“file://home/mneeraj/test.txt”);

● Ctx.getResource(“classpath:test.txt”);

● Ctx.getResource(“http://www.google.com”);

● The Resource interface has many methods to get the resource information like
getDescription(), contentLength(), exists(), getInputStream(), getFileName(),
getURI(), isReadable() etc.

● Recommended to use getInputStream() as this works across all file system,

classpath and url resources.
 Java Configuration
● Apart from XML based configuration of beans and application context, Spring also
allows a Java based configuration mechanism.

● Define all the beans in a Java configuration class by providing getters for each of the
required bean. Annotate those beans with @Bean annotation. You can also set the
properties on the bean by calling the setters appropriately in the @Bean methods.

● The Java configuration class needs to be annotated with @Configuration.

● Use AnnotationConfigApplicationContext class to set the application context from

the Java configuration class.

Additional Annotations:
● @ImportResource – can be used to load another XML file containing bean
configuration. This is not recommended as one needs to look at both XML and Java
classes for bean configuration. Use one mechanism.
● @PropertySource – can be used to load a properties file in to the application
context. This goes to Environment object.
● @ComponentScan – scans the given package to identify bean classes (ones
annotated with @Service, @Component, @Repository, @Controller) similar to XML
based component scan.
 Java Configuration
● @Import – can be used to import configuration from other Java configuration
classes.

● @Lazy – for lazy initialization of bean

● @DependsOn – to specify the other bean on which the current bean is dependent.

● @Scope – bean scope, singleton is default.

● Its recommended to use one consistent mechanism to maintain configuration either

XML or Java.
 Groovy Configuration
● With Spring 4, you can configure Spring applications using Groovy language

● Need to use GenericGroovyApplicationContext to create application context using

the groovy configuration script.

● For example, following groovy configuration script creates a bean named contact
from the Contact class and set the properties as well:
beans {
contact (Contact, firstName : 'Tom', lastName: 'Jerry')
}

● Groovy configuration is very powerful. You can create the application context as well
in the configuration script. Also setup profiles, properties.
 Profiles
● Can be used when one needs different set of beans based on the environment.
● For example, we have two implementations of Search interface, one for local search
and other for cloud search.

● Define two XML configuration files defining beans separately using local search
impelmentation and cloud search implementation. Set the profile attribute in the
beans element to local and cloud depending on the xml.

● When running the program pass the active profile name by the JVM argument
-Dspring.profiles.active=local or cloud.

● Same is possible via Java configuration. Define two separate Java configuration
classes and use @Profile annotation.
● Its possible to mark the active profile using the
applicationContext.getEnvironment().setActiveProfiles(“local / cloud”) as well.

● Developers can use it to define separate profiles for different run time environments.
For example, “dev” and “production”.

● The draw back is that the run time environment for all profiles need to be packaged
and can increase the size of application.
 Environment & PropertySource
● Spring while configuring the ApplicationContext also configures the Environment for
the application.

● The Environment contains System properties, JVM properties and Application

properties. We also used the Environment object to set the active Profile in the
earlier slides.

● Application properties can be loaded via the PropertySource interface.

● By default, the order is to search application properties in the end but this can be
changed via the Environment object obtained through
applicationContext.getEnvironment().

● Typically, an application wont directly use the Environment object but can use
property place holders in the XML configuration file like ${user.home}. To set this up,
need to define the <property-placeholder> for the context in the XML configuration
along with the path to the application property file.

● The local-override property allows application properties to take precedence if there

is a conflict with the system or JVM properties.
 Using JSR 330 Annotations
● Java EE 6 support JSR 330 annotations (dependency injection for Java)
● Spring has support for these annotations. If you use these annotations then it would
be easy to migrate from Spring to JEE or some other DI container like Google Guice.

● @Named – defines a injectable bean / component (also used to refer to a bean with
@Inject)
● @Inject – defines a particular (@Named) bean should be injected on the annotated
method / property
● @Singleton – marks a bean as singleton. By default the scope is prototype in JEE.

● Spring annotations are more feature rich and powerful, here are few differences:
● The @Autowired annotation can be marked with required to mark dependency

injection mandatory or use @Required annotation

● There is no equivalent to Spring's @Lazy annotation

● JEE has only two bean scopes singleton and non-singleton. While Spring has

additional scopes like request (create separate bean instance for each request)
which are useful in web applications.
Spring MVC
 Setting up tools
● Install JDK, setup JAVA_HOME and PATH
● Install Maven, setup M2_HOME, M2 (path to mvn command) and PATH
● Install Tomcat, use JDK path during installation
● In Eclipse/STS, link JDK (during install), Maven (Windows->Preferences->Maven)
and Tomcat (Windows->Preferences->Server)
 MVC
● Commonly used pattern for presentation layer. Supported by Spring MVC, Struts etc.
● Model – represents application state (specific to user session)
● View – representation of model, user interface
● Controller – gets the user action, interacts with service layer and updates the model.
Selects the appropriate view as a response. For AJAX based clients, it can return
JSON / XML (instead of view) to allow partial updates. Its important to know that the
response (rendered view) is also returned by dispatcher servlet.
 Spring MVC
● Most web frameworks have a dispatcher servlet which receives all requests and
triggers appropriate controller
● Spring MVC also has a DispatcherServlet. Each DispatcherServlet has a
corresponding WebApplicationContext that specifies servlet level controllers, view
resolving, i18n, theming etc. There can be multiple dispatcher servlets.
● There is also a root WebApplicationContext which represents application level
configuration.
● Filter is applied to every

●
request.
Common services are
defined for each
Spring MVC
webapplicationcontext
and applied to every
request like i18n,
theming, file upload.
● Handlers are methods for
particular HTTP request.
Annotated with
@RequestMapping.
● Handler Interceptors are
invoked before handlers.
Can check common logic
like only allow invoking
handlers during office
hours.
● Exception handlers are
methods annotated with
@ExceptionHandler to
handle specific
exceptions. Used in
mobile server e.g. auth
exception..
● View Resolvers pick
appropriate view based
on controller response.
 Spring MVC - Configuration
Configuration
● Configure web deployment descriptor (web.xml)
● Setup root web application context (path to root xml file)

● Setup filters & its mapping

● CharacterEncodingFilter – specify char encoding of the request, used in mobile

server as well
● HiddenHttpMethodFilter – allow HTTP requests other than GET/POST.

● Setup application's dispatcher servlet and specify web application context (servlet-

context.xml typical name). If you use the default naming format e.g. <dispatcher
servlet name>-servlet.xml and keep in WEB-INF/ folder then its automatically
picked up. All beans are defined here along with enabling annotation based
configuration.
● Define Spring's ContextLoaderListener for bootstrap & shutdown of root web

application context

Servlet 3 Code based Configuration

● With servlet 3.0 spec, you can configure the web application context without using
web.xml.
● Define a class implementing Spring's WebApplicationInitializer interface. Classes
implementing this interface are detected by SpringServletContainerInitializer class
which implements javax.servlet.ServletContainerInitializer interface.
● In this class override the onStartup() method and setup the dispatcher servlet along
with its properties.
 Spring MVC - Configuration
Spring Boot
● With Spring Boot, no configuration is needed and its all taken care by Spring Boot
build plugin. It embeds a web server inside the application and the output is a Fat jar
file. By default embedded server is tomcat but you can change it to jetty easily.

● However you can still use Spring Boot and configure it generate traditional war files
without embedded web server. Remove the spring boot build plugin from pom.xml
and change package type to war.
● Spring Boot actuator enables many endpoints for monitoring the application like
thread dump, bean information, metrics.
● There are third party metrics libraries which can be plugged in (like coda hale

metricsl)
● You can even SSH to the application and monitor it. Running thread information.

● You can also enable TLS on the Spring Boot embedded server easily. Need to define
a bean for EmbeddedServletContainerCustomizer.
 Spring MVC Basics
● The dispatcher servlet invokes the appropriate request handler based on the
@RequestMapping annotation. The value attribute in the annotation specifies the
URI that this handler should be mapped to.

● Spring provides a DI container that creates the beans and manages their life cycle.
This can be accessed via the ApplicationContext. The bean configuration can be
defined via XML, annotations or Java configuration (even Gradle).

● Spring MVC has WebApplicationContext interface that extends the

ApplicationContext interface . This manages the view related beans, message
converters, file upload etc defined inside the dispatcher servlet xml file. This works
with standard ServletContext (it adds a method getServletContext() to the interface).

● Typically we enable annotations in the web application context configuration

(<annotation-driven/>. This will allow use of @RequestMapping, @Controller,
@ExceptionHandler etc. It also enables conversion of Java object to/from
XML/JSON.

● We also typically enable component scan for automatic creation of bean objects
from a given base package via annotations.
 Spring MVC Error Handling
● Simpler error handling would constitute returning the HTTP status code
● 200 (OK), 201 (CREATED), 202 (ACCEPTED, resource yet to be created)

● 301 (Permanent Redirection), 304 (Not modified)

● 400 (Bad request), 401 (Authorization failure), 403 (Forbidden), 404 (Not found)

● 500 (Server error)

● However status codes provide basic error handling. Apart from status code, a
standard error structure can be returned to client, for example
application/vnd.error+json or application/vnd.error+xml. Spring HateOAS has
support for VndErrors.

● Writing vnd errors for each error condition is a pain and better way is to write
exception handlers (annotated with @ControllerAdvice) and throw exceptions for
all places where errors are generated.
https://blog.apigee.com/detail/restful_api_design_what_about_errors

● A controller advice class assists the controller class in various aspects like exception
handling. By default it covers all controllers.
 Spring MVC – File Upload
● Prior to servlet 3.0, apache commons file upload was the only option to upload files
● Define the multipart bean in the web application context xml file. In mobile server

we use this:
<beans:bean id="multipartResolver"
class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
<beans:property name="maxUploadSize" value="99999999999" />
</beans:bean>
● Use Spring's MultipartFile class in the controller to handle file upload. We use this
in mobile server (MultipartFile.transferTo() API).

● Servlet 3.0 spec defines in built mechanism for file upload. It uses
javax.servlet.http.Part class for this.
● To use this, define the file size limit in the web.xml. Define a bean implementing

MultipartResolver interface. Modify the controllers to accept file as request

parameter.
 Web Application Architecture
● Presentation Layer
● Controller, View, provided by Spring MVC. Typically controller will use Service

layer to access the domain objects from the repository.

● Services Layer
● Captures the business logic, works with domain objects and executes a

transaction.

● Domain Layer (Model)

● Represents the entities and their attributes that are required by the business. (See

sample domain model in image)

● Also represents relationships between entities
 Web Application Architecture
● Persistence Layer / Repository
● Main function is to map the domain objects to the data source and save the

changes in domain object to data source.

● Spring provides @Repository annotation to mark repository objects for accessing

data. These support CRUD operations on domain objects.

● Important to use interfaces for the repository classes and use them in the

controllers instead of tying to any particular repository implementation like SQL or

NoSQL.
 Spring MVC Controller
● Handles the web requests, a class annotated with @Controller. Can be
automatically discovered if component scan is enabled.
● Has @RequestMapping annotation on the methods that handle particular URI.
● At class level @RequestMapping specifies the base URI that needs to be prefixed
to every handler URI.

● URI Template allows a particular portion of the URI to be a variable. This can be
passed as an argument to the request handler which can take some action. For
example, /iprint/printers/airprint, /iprint/printers/email, /iprint/printers/mobile, here
only last element in the path is changing. To handle this in single method, use
/iprint/printers/{printerType}.
● Use @PathVariable annotation to read the path variables in the handler method
arguments.

● Matrix variables is another way to read values from the URI. It allows reading
name/val pairs and even multi-valued variables from the URI.
 Reading URI Variables
● Matrix variables is another way to read values from the URI. It allows reading
name/val pairs and even multi-valued variables from the URI.
● /iprint/printers;airprint=true;email=false

● /iprint/printers;id=7flr1,7flr2,7flr3

● The major benefit is ability to specify multi valued attributes and reading them in a

Map<String, List<String>>. Use @MatrixVariable annotation.

● Need to enable matrix variables in the <annotation-driven> tag of spring

configuration e.g. <mvc:annotation-driven enable-matrix-variables="true"/>

● Another way is to read query parameters from th URI / Request Parameters. Use
@RequestParam annotation.

● http://localhost:8080/WebStore/products/product?category=laptop&price=700
● public String getProducts(@RequestParam String category, @RequestParam
String price) { }
 View
● The View interface has render(Model, HttpRequest, HttpResponse). This interface is
implemented by many view technologies like InternalResourceView, VelocityView,
TilesView, RedirectView, FreeMarkerView.

● Controllers work with this interface thus any view technology can implement this
interface and work with Spring MVC.
● Use a view resolver to find the actual view instead of hardcoding (tightly coupling)

the view object in controller

● Redirect View
● Forward/Redirect requests from one controller method to another

● Forward keeps the original request parameters and sends to the target controller

method
● Redirect generates a new request to the target and existing request parameters

are lost.

● To get the response in JSON / XML (both for view or REST), add dependency on
jackson-mapper-asl (json) and Spring oxm (xml). Use @XmlTransient /
@JsonIgnore to mark a particular field that should not be added to the response.
Use @XmlRootElement to mark the class name as the root.
 Exception Handling
● @ResponseStatus annotation can be used to mark an exception class with status
code and message. Whenever that exception is thrown, Spring automatically takes
care of sending the appropriate status code and message.
● This annotation can also be used for a method to mark the status code returned by
that method.

● @ExceptionHandler annotation is used to mark a particular method as the handler

for a particular type of exception. This handler can return a particular object / string
apart from the HTTP status code which is marked with @ResponseStatus
annotation.
 Interceptors
● Can be used to hook into various stages of request processing by the handlers.

● Interceptors can be created to do some checks / auditing / logging / i18n

(LocaleChangeInterceptor) at various stages of request handling. You can define the
interceptor by either implementing HandlerInterceptor interface or extending
HandlerInterceptorAdaptor class.

● There are 3 stages which can be intercepted, before processing begins

(preHandle), after handler is done with request (postHandle), just before sending
the response to client (afterCompletion).

● Need to add the interceptor class as a bean to the application spring configuration
xml as an interceptor.
● Interceptors can also be used to do special handling for certain scenarios, for
example promotional offers.
 Spring Security Overview
● Can be used to add authentication and authorization to all layers including
presentation layer. Can be used for Spring MVC, REST and any non web based
application as well.
● Has authentication providers for LDAP, AD, PAM, Oauth and many more.
● Provides protection against many attacks like XSS, authentication & authorization,
session fixation, encryption etc.
● Spring Security also supports client authentication using certificates.
● One can setup an OAUTH Provider (which issues tokens) and validates those
tokens (OAuth Consumer)
● There is a inbuilt support to write unit tests to validate Oauth functionality. Basically
obtain the access token using mocks and leverage for futher unit tests.

● Add a filter (DelegatingFilterProxy) for intercepting requests in the web.xml.

● Create a Spring Security configuration file for authentication mechanism. The
auth mechanism can be LDAP, SSO.
● Add this file to the root web app context.
● To allow authentication handler at the method level, need to update web
application context xml with Spring security annotation handler. Use
@PreAuthroize annotation for this.
 REST
Reference:
1. RESTful Web APIs, Leonard, Mike, Sam
2. RESTful Web API with Spring, Josh Long
 REST Basics
● HTTP is stateless. Each request is handled independently.

● Any thing that needs to be referenced by the client as an independent entity is a

resource.

● Each resource has a URL

● Each resource has a corresponding representation that is delivered to client when it

access the resource. A representation describes the resource.

● Application State represents the page that is loaded on the client web browser.

● Each resource has a state maintained by the web server. This is known as
Resource State.

● A client can initiate a resource state change by sending a representation (HTML form
submission / POST). Similarly server can change the application state by sending
the new representations of the web page. This is known as Representational State
Transfer. In another words, server sends a representation describing the current
state of the resource while client sends a representation to indicate the desired state
of the resource.
 REST Basics
● All the web pages are connected via the hypermedia like <a> and <form> tags. This
drives the flow of application state (what pages client can navigate). Hence the term
'Hypermedia As The Engine Of Application State' (HATEOAS) is coined.

● The API (REST / Web) needs to be self descriptive using the hypermedia controls
so that client can discover the related resources and use them without following any
documentation.

● Also the API should not customize HTTP behavior to avoid requiring clients to use
some custom library. Lastly changing the API should not break the client. This all is
possible if APIs use basic HTTP concepts and are self descriptive.

● Think from web site and browser perspective. One browser can access any web site.
Even if web site changes still browser can access it. This works because all web site
pages are self descriptive (connected via hypermedia and have descriptive text). We
need to design web API's in a similar way.

● However one important difference is that a web browser is used by human beings
who can make decision on which link to click on a website by reading the description
but same is not true for web APIs as these are used by software agents. Some
predefined semantics are needed to define the hypermedia. This is a major
challenge. Need to read chapter 8 of the book to get better understanding. Anyways
it would still make it easy for developers to use.
 HTTP Basics
● HTTP request
● Sent by the client if HTTP verbs like GET / POST / DELETE etc along with the

resource URL
● HTTP Response
● Status code indicating request processing status (200 – OK)

● Content type indicates the resource representation type (aka mime type e.g.

text/html, application/json)
● Entity body (resource representation)

● HTTP Methods
There are 8 methods in the RFC 2616. Below 4 are commonly used:
● GET – gets the representation of the resource (represented by URL). Default

method in browsers. Does not change the state of the resource / no side effects.
● POST – used to create resources. The response status code should be 201

(created) and a location header providing the url of the newly created resource.
● DELETE – destroy the resource

● PUT – update the resource with a new representation

Below 2 methods are optionally used by client to discover the API:

● OPTIONS – which HTTP methods this resource supports

● HEAD – get the HTTP headers for the resource but not the representation (body).

Lightweight version of GET, can save network bandwidth.

Other 2 methods (CONNECT, TRACE) are used in HTTP proxy scenario.
 HTTP Basics
● There is another HTTP method (PATCH) thats not common but described in HTTP
supplement (RFC 5789). This is used to make fine grained changes to resource, it
can ignore some part of the resource representations.
● Below are two proposed extensions to HTTP standard (currently in draft state):
● LINK – connect another resource to this one

● UNLINK – disconnect some other connected resource from this resource

● GET
● Gets the representation of the resource

● Safe method, does not modify the resource. However some logging / auditing is

ok.
● Common response is 200 (OK) or 301 (moved permanently)

● DELETE
● Removes a resource from the server

● Multiple delete requests for the same resource have no additional effect other than

that one request succeeds.

● Server responds with

● 204 (No content) deleted and there is no more message from server

● 200 (ok) deleted and there is a message from server

● 202 (accepted) request accepted, deletion will happen after sometime.

● 404 (not found) / 410 (gone) – resource to be deleted does not exist
 HTTP Basics
● POST.
● Creates a new resource

● Sending multiple POST requests will create multiple resources

● Response

● 201 (created), accompanied with Location header indicating the newly created

resource url
● 202 (accepted), request to create resource accepted but not completed/started

yet.

● PUT
● Modifies an existing resource

● Sending same put request multiple times has no side effect

● PUT can be used to create a new resource if the sender knows the url of to be

newly created resource

● Response

● 200 (ok) successful, followed by the updated resource representation

● 204 (no content) successful but no message

 HTTP Basics
● PATCH
● PUT requires entire representation of the resource to be resent along with

changes. This can be very inefficient for large representations and minor changes.
● PATCH allows sending delta changes (diff). There is a standard for XML and

JSON based diffs.

● Multiple patch requests may have side effects.

● Response is similar to PUT (200, 204)

● Not part of the HTTP spec and is an extension defined for the web API. Tools may

not have support for this as it was published in 2010.

● LINK / UNLINK
● Allow a connection to be created/destroyed between current resource and some

other resource
● Used to manage hypermedia links between resources.

● In draft stage, avoid using them.

● HEAD (nothing more to cover than earlier summary)

● OPTIONS
● Allow a client to discover what HTTP methods are supported for a resource. The

response contains “Allow” header. For example:

Allow: GET PUT DELETE HEAD OPTIONS
● Not commonly used. Better design is to use hypermedia to describe the resources

which clients can use to determine what APIs are available.

 HTTP Basics
● Typically you should use only 4 HTTP methods GET, POST, DELETE and PUT
which is standard

● However depending on what kind of HTTP client/servers are there in the ecosystem,
one may want to use OPTIONS or HEAD request.

● PATCH request should only be used when you have full control of clients / server as
its a new option and not supported by many HTTP implementations

● WebDAV protocol defines additional HTTP methods for file handling like MOVE,
COPY, LOCK which can be used in file based applications.
 JSON Basics
● JavaScript Object Notation
● Mime type “application/json”
● Based on JavaScript notations and used to represent data structures in language
neutral text format
● Conventions
● A list of values (array) is enclosed in square brackets e.g. [1,2,3]

● A collection (object) is a key value pair e.g. order {“id” : 1, items : [“a”, “b”, “c”]}

● A value can be string, number, object, array, true, false, null.

● All strings to be enclosed in quotes e.g. “this is a string” represented in unicode.

 Collection+JSON
● Built on top of JSON, mandates publishing a list of HTTP resources related to
current page
● Content type is “application/vnd.collection+json”

● This list is defined as a collection object in the response e.g.

“collection” : {
“href” : “http://xyz.com/api/self“,
“items” : [
{ “href”: “http://xyz.com/api/next“ },
{ “href”: “http://xyz.com/api/prev“ }
]
}
● It also defines a template object (in the response) which client can use to send

(POST) data to the server. For example:

{ "template":
{
"data": [
{"prompt": "Text of the message", "name": "text", "value": "Squid!"}
]
}
}
● The benefit of using this representation is portability across various REST APIs if

they also use collection + JSON. There is a Java implementation (hamnis).

 Hypermedia
● Defines what resources (and their URLs) are available to clients along with their
capabilities (what operations client can invoke and how)
● Key to increasing the usability and stability of the web APIs
● Examples of hypermedia controls
● <a> – connects another resource to current page. Requires user to click.

● <img> - embeds an image into the current page. No user operation needed.

● <form method=POST> - sends a new representation to server. User intervention

needed.
● <form method=GET> - request a new representation to server. User intervention

needed.
 Hypermedia - URI
● URI Template
● URI type string that contains variables enclosed in { } which can be expanded to

produce the actual URIs e.g.

http://example.com/search/{query} can be expanded to
http://example.com/search/rest

● Every URL is a URI as well. A URL always has a representation while a URI may not
have. URI example thats not an URL, “urn:isbn:944849223”
● URI identifies a resource and is a superset.

● URL additionally identifies the mechanism to locate the resource like protocol http,

ftp and the location www.example.com/search.

● URN is a globally unique name for a resource independent of its location/protocol.

e.g. ISBN number of book

 Hypermedia - Purpose
Guiding the Request
● Hypermedia tells the client about the location of the resource, what http method to
use in the request, what http headers to set while accessing the resource and details
about the request body.
<a href="http://example.com"> click here</a>
● above tells URL and HTTP method (<a> tag means use GET method)
● HTML forms let you specify the headers (content type) and the request body when
accessing a resource.

Promising the Response

● <img> tag indicates that a binary image file would be sent if a GET request is made
for this resource

Workflow Control
● hypermedia describes the relationship between resources. <a> tag is an example for
this. Clicking it takes the browser to different page. Its an outbound link
● <img> is an embedded link and does not take the browser to different page.

● Note: JSON does not have hypermedia / url type. URLs are also represented as
string. Client needs to be informed via documentation about this.
 Link
● HTTP also defines a "Link" header which is similar to <a> html tag. It can be used to
establish links for entity bodies that do not support hypermedia like binary image
files. e.g.
HTTP/1.1 200 OK
Content-Type: text/plain
Link: <http://www.example.com/story/part2>;rel="next"

● The HTTP LINK and UNLINK extensions also use the same header.

● Link tag is used to link two resources. Browsers typically support it only for linking
external style sheets. There is no end tag for this. It does not show up in the UI.

● Link relation attribute (rel) is what gives meaning to the relationship between two
resources (current and some other resource). The meaning depends on the domain.
This is where domain specific semantics come into picture.

● There is a link relations registry maintained by IANA, use those when appropriate.
While defining new relation names ensure they do not conflict with IANA names.
 REST API Design Steps
● Identify what information client needs to access? Think about the structure of this
information. Typically its a hierarchical structure. For example, Printer->Name
(printer contains name). This is known as semantic descriptors for the application.

● Group the descriptors in their logical separate representations and Identify the
relationship between the different representations. Create a state diagram and put
names for each state transition.
 REST API Design Steps
● Try using the IANA approved link relation names for your state transitions if possible.

● Decide on the media type. JSON does not have hypermedia so you might want to
use some other richer media type which can represent hypermedia like JSON-LD
(W3C standard) and HAL.

● Write a profile for your application semantics and embed those links in the response.
This will help client in understanding the meaning of various semantic descriptors
and their relations.

● Write Code

● Publish your home / start URL. This should be the only URL that you need to publish
and client should be able to discover the remaining API on its own.
 REST API Design Guidelines
● Think in terms of the information to be returned to the client but not the URLs
● Use standard names for semantic relations / link rels and attributes.
● Do not map the database schema to the resources / api. It would become difficult to
extend the schema later on as clients will break.

● Versioning the API

● Partition the url space for old and new versions /v1/api & /v2/api. New clients will

use /v2/api while older continue to use /v1/api

● Use standard content type and Profiles to capture application semantics. You can

create multiple versions of profiles and client can pick any.

● You may use different media types for different versions, however this is normally

not recommended. Sometimes media type is not under our control completely e.g.
if the client is using HTML5 form to talk to REST API.

● If you use hypermedia properly then versioning is not that critical. Hypermedia lets
you design APIs that can change easily. Two things to keep in mind:
● Server should not dump all hypermedia in single file and let clients use it, like

WSDL for web services. This will still lead to tight coupling and break clients when
APIs change. Instead put hypermedia controls that are relevant to current
resource state in a given resource.
● Clients need to discover the possible state transitions based on hypermedia and

use them.
 REST Client
● Java API for JSON Processing (JSR 353)
● Use Java's URL class to open a connection to the REST service.

● Simply pass the InputStream obtained from the connection to JsonReader

● Invoke getObject() or getArray() methods on the JsonReader to access the

response in the form of an object.

● There are methods available to get the attribute values using key values

● Above is the Object Model API (DOM style), brings entire response in memory.

Other option is to use Streaming API (SAX style) which lets you parse the
response line by line.

● Spring RestTemplate
● This is even simpler way to write REST client but pulls in lot of Spring framework

dependencies.
● Uses HttpClient and Jackson Json mapper underneath

● Create an appropriate response mapping class and annotate it using Jackson

@JsonIgnoreProperties(ignoreUnknown=true) to ignore additional response

attributes.
● RestTemplate provides large number of HTTP methods to invoke on the given

URL.
● Just inovke RestTemplate.getForObject() method and pass the URL along with

object type to be mapped.

 Spring TEST
● In built support for Spring MVC
● Requests are directly sent to DispatcherServlet without running a real web server.
Hence more realistic tests with high performance.
● A mock MVC server and client is created. Client can be used to send requests and
verify the response (status code, content type, headers, content). Basically its
MockHttpServletRequest and MockHttpServletResponse.
● Has annotations to setup DB transactions which can be rolled back once test is
complete
 Spring REST Example
● Spring Boot simplifies building REST based applications even further
● Every Spring Boot application has a main method which initializes the application.
For Spring MVC, need to extend from SpringBootServletInitializer (need to read
more about this – TBD)
● Spring Data REST allows exposing the database repository over REST.
● @RestController annotation marks a Spring MVC controller as REST controller. TBD
● @RequestMapping
● @PathVariable
● @ResponseEntity
● HttpMessageConverters
● Setting up custom HTTP headers (prefix with x e.g. x-foo)
● Setting up the HTTP response code
● ServletUriComponentBuilder
 REST
● There is no standard but its an architectural
style
● Based on HTTP verbs which map to life
cycle states of resource (read, write, delete,
modify)
● Helps building a distributed system
● SOAP based web services are heavy and
many vendors do it differently
● Richardson maturity model
http://martinfowler.com/articles/richardsonMaturityModel.html
 HTTP Verbs

● GET
– Retrieve information
– Should not have side effects
– Repeatable (same data can be asked
multiple times)
– Can be conditional/partial (if-modified-since /
range)
– GET /users/22
 HTTP Verbs

● DELETE
– Removes a resource
– Delete /users/21
 HTTP Verbs

● POST
– Mostly used for creating resources (though
sometimes used for updating as well)
– The request body contains the details of the
resource to be created
– POST /users/21
{ “firstname” : “neeraj” }
– Once the resource is created, server sends a
HTTP 201 along with the URI of the newly
created resource in the Location header
 HTTP Verbs

● PUT
– Used for updating resources
– PUT /users/21
{ “firstname” : “neeraj” }
HTTP Status
HTTP Status
HTTP Status
 HTTP Content Negotiation

If Client specifies it accepts JSON while server only mentions XML in the
Content-Type then the negotiation would fail with 406.

Accept header & Content-Type describe mime types.

We can create custom mime types as well to specify new versions of the
APIs and maintain compatibility with older versions.

Spring MVC support multiple content negotiation strategies using

ContentNegotiationStrategy which can be extended if needed. Though
mostly accept heander and content type would be sufficient.
Richardson Maturity Model

HATEOAS (Hypermedia As The

Engine Of Application State), enables
Discovering the capabilities,
decouples Client and REST services.

HTTP verbs and response codes are

used.

HTTP URIs are used to identify

resources so there are multiple end
points.

HTTP is used just as tunneling

mechanism e.g. SOAP, XML-RPC. All
requests go to same end point.
 Spring Steorotypes
● @Component
For any generic Spring managed component.
● @Controller
For presentation layer
● @Service
For service layer, business logic.
● @Repository
Used to mark data access layer
 @Controller
● Defines a web request handler. Dispatcher servlet delegates the request to one of
the controller.
● Can specify the uri to be handled at the class level
● Each method can define the sub uri that its responsible for along with the request
type. Method also defines the response type.
 Spring Data

Service/Application

Spring Data / Repository Converts

What → How

SQL, NoSQL
Data Backends (MongoDB), Apache
Hadoop, REST etc

https://www.youtube.com/watch?
v=P05GlyrIz0o
 Spring Data

● Allows mapping of POJOs to/from data

backends
● Based on adapter pattern (converts what to
how)
● Provides repository interfaces for various
backends which are automatically
implemented during runtime
– Can be customized using annotations
– Manually overridden
 Spring Data
● Mapping is inferred automatically but again
annotations can help to drive this.
● Template classes allow direct access to
backend but still automatically manages the
resources (like closing the connection)
● Query support
– Auto generated based on method name
– Native query using @Query annotation
– DSL (Domain Specific Language) which is a
neutral format automatically translated to
native
 Spring Data - MongoDB
● Creates object IDs in client and not in
server
● Object IDs are based on 12 byte UUID
– Mapped to String or BigInteger in Java
● Does not support explicit transactional
model. It has a atomic update model.
@Transactional not used by MongoDB.
Spring Boot
Spring 4
 Spring MVC

● WebApplicationInitializer is equivalent to
web.xml.
● Helps in registering controllers, filters
programmatically for the web app
● Spring Boot even simplifies the
configuration further.