Spring contains some nice guide how to setup a simple service for a pojo/data repository based on JPA. Unfortunately I can not find the client side implementation or a good example how to access this service via Java itself. In the example there is only shown basic curl access. Maybe I am missing some fundamental basics but in the WEB I only found some basic Rest examples and also a consuming guide by Spring itself. IMHO these are quite low level, I am looking for a more sophisticated annotation driven implementation possibility.
Why not look at Feign in the context of spring-cloud. It is an declarative Rest client that is originally developed at netflix and has become part of spring-cloud. It also nicely integrates some service discovery solutions that are available in the spring-cloud context.
http://projects.spring.io/spring-cloud/spring-cloud.html#spring-cloud-feign
Feign is a declarative web service client. It makes writing web
service clients easier. To use Feign create an interface and annotate
it. It has pluggable annotation support including Feign annotations
and JAX-RS annotations. Feign also supports pluggable encoders and
decoders. Spring Cloud adds support for Spring MVC annotations and for
using the same HttpMessageConverters used by default in Spring Web.
Spring Cloud integrates Ribbon and Eureka to provide a load balanced
http client when using Feign.
A feign client could look like this:
#FeignClient("stores")
public interface StoreClient {
#RequestMapping(method = RequestMethod.GET, value = "/stores")
List<Store> getStores();
#RequestMapping(method = RequestMethod.POST, value = "/stores/{storeId}", consumes = "application/json")
Store update(#PathVariable("storeId") Long storeId, Store store);
}
Related
I have to integrate spring rest docs in a legacy project were they use a bunch of custom annotation (such as for example the user roles).
Is there a way in spring rest docs to document this annotation?
Spring REST Docs works at the level of HTTP requests and responses. By design, it doesn't know anything about annotations or how those requests are handled and the responses created. This ensures that what you're documenting is at the same level as a client interacting with your service over HTTP.
If you want to include information about #PreAuthorize or an annotation that is similar to it, you will have to write something yourself to do that. If you want to fit into the REST Docs way of doing things, you could implement a custom Snippet that's configured with a class or method from which it extracts the annotation using reflection and generates some documentation from it.
I've been trying to find a simple all purpose unit test framework for Spring MVC based Rest Services I've written.
I've been searching online and narrowed it down to:
RestFuse (http://developer.eclipsesource.com/restfuse/)
Rest Assured (https://github.com/jayway/rest-assured)
MockMVC (http://www.petrikainulainen.net/programming/spring-framework/unit-testing-of-spring-mvc-controllers-rest-api/)
I like RestFuse because it's mostly annotation based, but rest assured seems to have a easier way of passing parameters and checking responses. And finally being a Spring MVC Rest Service project, I'm wondering if I should just stick with the already established way of testing Rest Services in Spring with MockMVC.
Interested to get any feedback, as well as performance, past experiences and if there's anything else I should take into consideration.
Rest-Assured is gaining acceptance over the other frameworks to test REST services in Java. Having BDD style fluent interface, its easy to read the test scripts also, with minimal learning curve.
I am using this framework for verifying REST services as an end user, and it has been easier to implement test scripts for them. Hence I cannot comment much on Spring MVC part of REST-assured.
However, this blog post gives you more details on RestAssured v2.2 which includes spring-mock-mvc module built on top of MockMVC giving BDD style fluent interface flavor through REST assured. The blog post also cautions:
When not to use it:
RestAssuredMockMvc is not to be considered a complete replacement to
vanilla MockMvc since it contains more specific features coupled to
Spring MVC. For example right now there’s no first class support for
things like flash attributes and principals. You can how ever add
those by using an interceptor. Standard REST Assured also supports a
lot of different authentication schemes and filters which are not
available in the RestAssuredMockMvc API. Another reason for why you
may want to use the standard REST Assured API is if it’s important to
your organization to test the REST API in a real container (for
example if you’ve configured authentication or authorization in a
container specific manner) or if you’re using JAX-RS (or any other
framework regardless of language).
Finally, have a look at REST-Assured spring-mvc-webapp examples in REST-assured codebase, and decide, whether you like to give a try for it and make the best use of both REST-assured and MockMVC frameworks.
The beauty of MockMVC is that it provides a mock servlet container, allowing you to integration-test your REST services without deploying to a web server. I believe that you can still leverage this power when using REST Assured with the spring-mock-mvc module.
Another framework that I just learned of is Karate. Its author is currently experimenting with a mechanism to allow execution in a mock servlet container (see Peter Thomas' answer to Is there a mechanism for integration testing JAX-RS services without deploying (a la MockMVC)?).
I have a very simple service project (SpringBootApplication) that exposes a REST endpoint via a Spring Boot controller class. The controller maps an /events endpoint that converts a simple incoming event DTO into a slightly different event entity object that is then persisted in a database via a org.springframework.data.repository.CrudRepository instance.
In my controller, I am only mapping the POST operator because I don't want my clients to be able to GET, PUT or DELETE data from the service.
During a security scan today, I discovered that the service is exposing a /eventsEntities endpoint, which appears to be mapping all of the CrudRepository verbs into the REST endpoint.
Any idea how I managed to enable this automatic endpoint and more importantly, how to disable it? I'm using Spring Boot 1.2.2.
After some additional digging, I realized that I had inadvertently included org.springframework.boot:spring-boot-starter-data-rest in my compile dependencies. That starter includes spring-data-rest-webmvc, which exposes JPA data over REST. Removing that dependency resolved the issue.
Hope my realization helps someone else in the future.
Given that one of the main benefits of Spring Data and the related REST repositories is that most of the time the developer doesn't have to worry about the underlying implementations, is there an out-of-the-box way to leverage the Spring Cloud Netflix libraries, specifically the Hystrix annotations in this case, without extending every call in the provided Repository interfaces or creating my own implementation?
Currently you need to wrap calls in another service whose methods are annotated with #HystrixCommand. Because of the way both Spring Data and the Hystrix Aspect work (they both create proxies), there would need to be specific integration in Spring Data for #HystrixCommand. #ccit-spence is right, you really want to put #HystrixCommand on the services calling into a Spring Data REST repository.
I'm a seasoned Java developer but new to GWT.
Consider a 3rd party http POST based webservices api, not completely REST based since there's configuration of servlets, among other things, to invoke these services. I'm building gwt components extending the base gwt composites and using these 3rd party data services to fetch/mutate the data.
In the normal java world, I'd have build a REST wrapper on these services and exposed them as Pojos via JaxB Xml/Json. In GWT, however, I read GWT-RPC will be the fastest, given the serialization required. The data is expected to be large (several thousands, paginated).
What's the best way to design the 'bridge' between the 3rd party data services and the gwt client components?
I ruled out RequestFactory since we have a custom servlet provided by the 3rd party that fetches the webservices.
Adding a rest wrapper adds a 3rd layer of indirection (3rd party api+rest+gwt-rpc serialization) that felt too heavy
Suggestions for a low latency design, where I don't have to write too many wrapper classes for each service call (pojo)?
I'd like to consider jaxb on the server side, making schema as the new contract, and converting them to JSON for gwt-client.
I am using RestEasy on the server side, which uses Hibernate JPA to access database. With a little modification, I should be able to switch over to Datanucleus JPA.
I am using RestyGWT on client side.
With careful consideration on the DTOs, I am able to
- share the same DTO between server and client
- share the same REST interface between server and client (after running a script over the server side REST interface to transform the return type into an async callback).
Integrating multiple GWT applications into a pluggable platform.
Currently I am also trying to merge JPA DTO with REST DTOs so that I have a single set of POJOs between server, database and client. Each DTO POJO would therefore have a mix of JAX-RS, JAXB, Jackson JSON and JPA annotation.
To reduce unnecessary client-server traffic, I use JSP as GWT hosting file in tandem with GWT Dictionary class to transfer all session-specific session-static information to the client.
My Suggestion would be to use Spring RestTemplate, Gwt-RPC and have a RemoteServiceServlet/Spring bridge - that would give you RPC calls via a POJO from Server-Client and a clean tier to communicate with your external web services..
This will be lightweight and clean..