This is a Spring RESTful Service secured with Spring Security - it provides a Proof of Concept implementation of a REST service with Spring and Spring Security. It also provides a reference implementation in the following connected areas:
- REST Discoverability and HATEOAS
- Basic and Digest Authentication
- support for Multiple Representations (on the same URIs) (JSON, XML)
- a full REST based query language for advanced filtering of resources
- sorting and pagination in REST
- Statelessness for REST with Spring
- full integration testing suites at every layer: unit tests, integration tests for the DAO and Service layers, integration tests against the REST service
- CI server: https://rest-security.ci.cloudbees.com/
The project uses the following technologies:
- web/REST: Spring 3.1.2
- marshalling: Jackson (for JSON) and XStream (for XML)
- persistence: JPA, Spring Data JPA and Hibernate
- testing: Junit, Hamcrest, Mockito, rest-assured
- to create a new DAO, only the interface needs to be created; Spring Data JPA will generates the DAO implementation automatically
- the DAO interface MUST extend the Spring Data managed interface: JpaRepository (with the correct parametrization)
- the DAO layer is aware of the persistence engine it uses; this information MUST be encoded in the name; for example: IPrincipalJpaDAO for JPA instead of just IPrincipalDAO
-
all Service interfaces MUST extend the IService interface (with the proper parametrization)
-
all Service implementations MUST extend the AbstractService abstract class (with the proper parametrization)
-
extending AbstractService and IService enables a base of consistent and common functionality across services
-
the Service artifacts MUST be annotated with the @Service annotation
-
the Service layer is not aware of the persistence engine it uses (indirectly); if the persistence engine will change, the DAO artifacts will change, and the service will not
- the Controller layer MUST only use the Service layer directly (never the DAO layer)
- the Controller layer SHOULD not implement any interface
- the Controller layer MUST extend AbstractController (with the proper parametrization)
- the Controller artifacts MUST be annotated with the @Controller annotation
- the Service layer is the transaction owner (and is annotated with @Transactional)
- the default transaction semantics are: propagation REQUIRED, default isolation, rollback on runtime exceptions
- NOTE: the transactional semantics MAY be subject to change
- see the Eclipse wiki page of this project