The standard way for creating REST resources both in JAX-RS and Spring MVC is to use annotations. Jersey provides an alternative to using annotations, which is called Programmatic API for Building Resources. This can be used to create REST resources dynamically at runtime, for example from user input or configuration. With the annotations approach, in contrast, creating a new REST resource requires the usual develop/build/deploy cycle.
Is there an equivalent API for building REST resources programmatically in Spring MVC? I'm looking for working example code like in the Programmatic Hello World example of the Jersey user guide.
Related
I have spring boot app that provides openapi. I've used Swagger. I have a file that stores jsonSchema and I wanna to parse it into io.swagger.v3.oas.models.media.Schema to add it into Swagger. I can't find any existing solutions. Does any spring boot library supports this functionality?
Thanks.
If you are using Spring web MVC HATEOS endpoints, then you can directly use the https://springdoc.org/. Example: #RequestMapping, #GetMapping, etc.
Springdoc-openapi comes with ui and open api v3 docs generation.
IF not, and you prefer to use JaxRS2 to configure your RESTful endpoints, then use the <groupId>io.swagger.core.v3</groupId><artifactId>swagger-jaxrs2</artifactId>, and register your resources using JerseyConfig extends ResourceConfig and include io.swagger.v3.integration.sources for jaxrs2 scanning.
I'm using spring-mvc to create servlets like:
#RestController
public class MyServlet {
#GetMapping("/test")
public MyRsp test(MyReq req) {
//...
}
}
Now if the user accesses the root of my app localhost:8080/my-app, it should show a list of GET and POST methods available. At best with possible input parameters, acceptable headers etc.
Question: is that possible with any spring framework, like HATEOAS?
I'd expect a framework to auto detect any #RestController and included methods.
Or would I have to create that overview page myself?
You should must look into this
To integrate it in spring you can refer this
Swagger is one of the best framework to expose RESTful API's.
Swagger 2 is an another option. read the following to know more about swagger and how to set it up.
Setting Up Swagger 2 with a Spring REST API
You can also create swagger definition for your rest apis, which can be used by the clients to generate client classes.
Also the swagger ui can be used to test/invoke your APIs. swagger provides a user interface where you can input all the api inputs such as query params, path params, request body, headers.
Sample Swagger UI
You can check this project Spring Restdocs (github), which allows you to generate ready to use REST documentation. It's officially maintained by Spring Team:
The primary goal of this project is to make it easy to document
RESTful services by combining content that's been hand-written using
Asciidoctor with auto-generated examples produced with the Spring MVC
Test framework. The result is intended to be an easy-to-read user
guide, akin to GitHub's API documentation for example, rather than the
fully automated, dense API documentation produced by tools like
Swagger.
The other option is to use Swagger, it supports bottom-up approach as well:
A bottom-up approach where you have an existing REST API for which you
want to create a Swagger definition. Either you create the definition
manually (using the same Swagger Editor mentioned above), or if you
are using one of the supported frameworks (JAX-RS, node.js, etc), you
can get the Swagger definition generated automatically for you.
Some examples of swagger are mentioned here: 1 2
ive been tasked with a total refactor of legacy code. It's a simple webservice, just an http request, then business logic with possibly a few database calls and a few other microservice calls, then a json response. I am being pushed not to use spring boot because no one else around me has used it before, and I was told jersey does everything spring boot does. I've never used jersey so im trying to find out how to do things that spring boot makes simple (ie repository layer with spring-data, caching, spring-consul, spring-zuul, spring-actuator, spring-circuit-breaker) It looks like jersey does do an analog of spring-security, bean validation, and easy insertion of servlet filters, but not everything spring-boot does. Is there an easy way to wire in a JPA type repository in jersey? I cant find it in the docs at https://jersey.java.net/documentation/latest/index.html.
I think about it this way. There are different layers in your application. You have a service layer, and you have a "REST layer". You access the Spring repositories with the service layer. Then you have the REST layer. With Spring, you have Spring MVC which is its web layer implementation, that you can also use as REST services. There is also Jersey, which is completely independent of Spring, which is a another REST layer options.
That be said, when using Spring MVC as the REST layer, adding the service layer with Spring data is seamless. But Jersey also has integration with Spring, that allows us to use Spring at the service layer inside our Jersey REST services. You check out this post which has some links to example of how this can be done (no hacking, this is supported out of the box). Using this approach, you can just injector your Spring data repositories into your Jersey resource class
interface PetsRepository extends JpaRepository<Pets, Long> {}
#Path("/pets")
class PetsResource {
#Autowired
private PetsRepository repo;
}
Now lets talk about Spring Boot. Spring Boot is just a bootstrapping framework. What it does is allow you to easily bootstrap an application without all the boilerplate configuration you would need without it. When your using Spring Boot for your REST services, you're not actually using Spring Boot itself as the REST service engine. You are only using it to bootstrap Spring MVC and maybe your Spring Data. But Spring MVC is the actual REST service engine.
Now like I said before, Jersey has support for integrating Spring into into it (for the service layer). Because of this support, Spring Boot has also provided a bootstrap configuration to integrate this support seamlessly. So instead of using the manual configuration that you would see in one of the examples linked to above, Spring Boot handles this configuration for us. So we can use Jersey as the REST layer, and Spring beans as the service layer. Check out the links below
See also:
Spring Boot docs for Jersey support
I want to create a REST web service using Jersey. I also want to use Spring in the project. Now, my questions is the following:
I don't see any reason for integrating these 2 together in my application. So, I should be able to use Spring for bean management and Jersey for creating the web service. Am I correct, or Spring and Jersey somehow have to be integrated.
I see that there is a jersey-spring maven project, and so, I assume that this is for the purpose of integrating jersey and spring together. My question here is do I get any benefit of using this integrated form rather than simply use Jersey and Spring separately each for its own functionality?
Thanks,
Cyrus
You can absolutely combine the two projects. However, I would encourage you to look at Spring-MVC for doing REST as it is very powerful and easy to use. If memory serves, the jersey-spring project was helpful in integration of JAXB and other touch points. Again, this is all built into Spring. And if you use Spring-Boot it is amazingly simple to get running.
The jersey-spring project provides integration between Jersey and Spring. It allows you to wire in any beans in your Spring context into Jersey and vice-versa.
For instance, if you are using spring-security, it will provide your spring-security principal when wiring the Jersey specific SecurityContext into any of your REST resources.
If you want to access Spring beans from your Jersey REST endpoints (or use Spring Beans as implementations for your JAX-RS interfaces) you need to integrate Spring and Jersey, otherwise it won't work. If you don't have any connections between Spring beans and your REST endpoints, then it is not necessary.
I think your first statement is correct. I have used Jersey and Sprint as separate entities.
Jersey is really awesome to create a web server.
Spring is useful for dependency injection (beans) and other cools stuff.
About your second statement, I do not know anything jersey-spring maven project.
My suggestion/opinion is to do as your first comment. Use them in a separate way. You will have the best of both worlds. Using jersey-spring maven project might be a complication and maybe it is not what you want. Libraries usually are intend to be independent.
Question is, what's the difference between Spring HATEOAS versus Spring Data Rest ?
I feel both can do the same, and Spring Data Rest (as part of Spring Data) seems a bit more alive.
https://github.com/spring-projects/spring-hateoas
https://github.com/spring-projects/spring-data-rest
When would you use one or the other?
Spring HATEOAS provides common abstractions (representational models, a Link class, API to build links pointing to Spring MVC controllers, etc.) to ease building hypermedia driven REST APIs with Spring MVC in general. Thus, you can use it alongside Spring MVC to manually build those services.
Spring Data REST uses Spring HATEOAS to automatically expose resources for entities managed by Spring Data repositories and leverages hypermedia aspects to do pagination, link entities etc. So it covers the 80% use case for the basic stuff and allows you to selectively add more complex processes using manually implemented controllers later on.
To get a feel for this, feel free to have a look at the Spring RESTBucks sample project. The handling of Order instances is completely done by Spring Data REST (with some minor tweaks to implement business constraints). The entire payment logic is then implemented manually as the process does not fall into the CRUD category as we actually need to implement certain steps and a protocol to complete the order. Again, the code is here, a slide deck with some additional visuals can be found at speakerdeck.com.
HATEOAS stand for Hypermedia as the Engine of Application State and is one of the key ponit of REST. Basically the key point consist to use links on the your resource representation for map the valid transition of the application state. In this case will be the service provider that provide the valid next correct state of the your application reachable through the link. Spring HATEOAS is the Spring projects for help to build the Hymeridia Controls in your Resource. It is a project integrate with Spring MVC and you can think as the Spring MVC extension for building a real RESTFull WS whit a very good support for increase the level of the your service form CRUD (level 2 of maturity in the Richardson model) to an Hypermedia aware (level 3 of maturity in the Richardson model). Spring Data Rest on the other hands is a very nice project that use Spring HATEOAS as basic brick, for give you a repository layer usable as restfull ws. In proctis the project help to reduce the classical boliporlent code for expose the your repository layer as a restfull endpoint. We can say tat was the propouse of the projects very different. With Spring HATEOAS you had a framework usable for any kind of restfull endpoint, with spring data rest you had a spring project that already provide an endpoint and a framework for customize it.
I hope that this reflections can help you to clarify the difference between the two projects and understand better how use one or the other
I chose to use both of them in my project. One layer of controllers was built with Spring Data REST. The other layer of controllers was #RestController's (spring-wevmvc). In this layer I used Spring HATEOAS to create customed page's.
(Process was :
1.creating Pageable Pageable pageable = new PageRequest
2. creating new Page Page<FooDt> page = new PageImpl<FooDt>
3.creating PagedResources PagedResources<Resource<FooDt>> resource = fooAssembler.toResource(page, fooAssembler) after that process using Jackson's ObjectMapper to return json.
The solution that I found for loading to context both technologies - is using two DispatcherServlet's.
Otherwise, Spring Data Rest is taking control and there is no option to use other controllers. ( In that way I had two domains in my app. One for Data Rest and one for webmvc+HATEOS).