So I've been working on a microservice-based architecture in Spring and my prototype uses Spring's WebClient to explicitly send a request to a different service and await a response. Recently I've tried to migrate the project to some RPC-based service remoting technology, and I figured out that all the technologies that just work out of the box (Hessian, RMI, HTTP Method Invoker) are deprecated, and the ones that Spring encourages to use (JAX WS and Spring WS) require to learn multiple additional DSLs and spend a week trying to deeply understand their principles just to export a service to the web. Also, just using WebClient feels far more flexible and seems to leave a lot of room for further improvements. Will creating my own REST-like APIs for each of the microservices and then explicitly using WebClient to call them turn my code into instant legacy spaghetti mess or is it a normal thing to do?
P.S. By "more flexible" I mean, for example, an ability to set up a reverse proxy load balancer with caching and different actions for different methods in between the actual microservice nodes and the requesting service, etc.
Related
I am trying to build a new application with spring boot microservice framework. I have tried some demo. The existing demo is too simple, doesn't introduce how to call another service from one service. Should still going through http, or should going through RPC? If going RPC, which RPC framework support?
The way of integrating among services depends on numerous factors, like synchronicity/asynchronicity, load that will be generated, etc. The most popular (I guess) way of integration is REST-based one. Because you tagged your question with spring I would recommend using declarative REST client - Feign that is very well described here. You can use message brokers as well, which are also very well abstracted by Spring Cloud Stream - you can read more here. I think that more in depth discussion should be based on your needs.
If another micro-services are exposing the REST API , then you can simple use jersey client
or httpclient to call them.
I have worked on RESTful Web Services at a high level (not very exhaustively), coded few REST based web services.
To begin my journey in RESTful WS, I read online articles (wiki, online tutorials etc.) and I came to know that it is an architectural style specifying constraints and when applied to web service induce desirable properties, such as performance, scalability etc. Ok, this is the theory part of this concept.
A simple example using JAX-RS:
#Path("/simple")
public class SimpleRESTService {
#GET
#Path("/{param}")
public Response getMsg(#PathParam("param") String message) {
String output = "Jersey say : " + message;
return Response.status(200).entity(output).build();
}
}
My doubt is:
If REST is architectural style (and using those guidelines build RESTful web services), what does JAX-RS do? To what I understood, REST is just architectural style and not any specification, what does JAX-RS has to do with this? I am having difficulty in understanding the relation between these two entities.
Can anyone help me understand this in simple words.
REST is indeed an architectural style of building web services independent of application-layer protocols (it could be implemented over FTP or HTTP as well).
JAX-RS is just a standardized API of Java EE with which you can easily implement RESTful services in Java. It is a toolkit for a developer to lift the burden off his shoulders, and as part of Java EE, it is implemented in application servers such as WildFly out of the box.
But note that it is just as possible to create REST services in frameworks like Spring using the Spring Web MVC and Spring HATEOAS modules.
Edit:
Although REST is a well-defined architectural style, it is (as you mentioned) not a specification so there is a lot of foggy areas about it among developers.
In a nutshell, all it states is "Hey man, if you use the communication protocol (say HTTP) this way and this way, it will be very convenient for you to change and scale and it will be very straightforward for the clients of your service to talk to you".
JAX-RS gives you the ability to define service endpoints with dynamic parts (eg.: /api/jediknights/{id}, so that the id could be anything), makes it easier to respond to the client in the format of your (or your client's) desire, like XML or JSON. It provides convenient wrapper objects to wrap your response body along with status codes and headers and many other things of convenience.
The catch however is: it is still your responsibility as a developer to adhere to the principles stated by the REST style. Nothing is really enforced upon you by JAX-RS.
To be fair, you could even achieve a RESTful web service by only using the somewhat lower-level Servlet API. JAX-RS just hides the unnecessary details from you and will make your life easier.
I hope it became a bit clearer :)
Java API for RESTful Web Services (JAX-RS), is a set if APIs to
developer REST service. JAX-RS is part of the Java EE6, and make
developers to develop REST web application easily.
You can read some more here: http://www.mkyong.com/tutorials/jax-rs-tutorials/
I am using vertx3.
As we know Vertx is very efficient handling many requests with it's reactor pattern.
The thing is that I have a second service which exposed as Rest-API on Spring-boot container(it was very easy for me to implement it over there).
I got two options: 1. Implement that logic on vertx and earn the api call.
2. Scale the spring-boot service to handle those millions rest api's reuqests from vertx.
Anyone had this dilema ?
will be easier to go with option two.
Any alternative how to scale the spring service ?
(I already aware to the physical solutions of adding many instances on diff machines and put load-balancers but than I am losing the power of vertx since the spring-service is a bottleneck
Thanks,
ray.
Usually service implementations are stateless, regardless from technology which are you going to use. So it means, that they are scalable.
Try to implement service logic, using spring, rest-api using vertx. Spring service service logic will be used from vertx.
And of cause do not block the threads in service implementation.
I researched a lot about it, but I wasn't able to reach a conclusion about this matter.
I'm creating a new front-end in GWT, using GWT-Platform and GIN, for an existing application. But I can't figure out which is the best way to interact with the existing REST API.
What I found up to now is that I can use RequestBuilder to do the calls, and that also exists the RestyGWT framework for REST communications. But I don't know how to integrate any of them with GIN Injector. And I have doubts on how to translate the JSON return from the service to the JTO available in the client code translated by GWT.
The last one specially due to a legacy code that translate the Beans from the server to a kind of generic Json format.
So what I want to know is do anybody have experience integrating legacy backend to a new GWT front-end with REST. How they integrate both? How they solve, if experienced, the Beans integration?
I agree with Ümit, If you are worried about the "communication" between backend and frontend don´t get stress:
Something like:
public String serializeToJson(YoutEntity report) {
AutoBean<YoutEntity > bean = AutoBeanUtils.getAutoBean(report);
return AutoBeanCodex.encode(bean).getPayload();
}
public YoutEntity deserializeCompanyFromJson(String json) {
AutoBean<YoutEntity > bean =
AutoBeanCodex.decode(factoryYourEntity, YoutEntity .class, json);
return bean.as();
}
is perfectly possible using Autobeans!
And using GWT you can share your entities between Client and Server, so you don´t need to touch anything.
Also, in our last project using Apache Wink as a REST client, in the server using the correct annotations we were able to have the Entity automatically from the JSON, so is even easier (but I think most of the REST libraries can do the same).
Thanks!
Your question touches a couple of different aspects both client-side but also server-side.
In general there is nothing special about integration between GWT and a REST API.
On the GWT side there are different ways to consume a REST API:
RequestBuilder to manually create the HTTP Requests to the REST API. You have to parse the JSON payload. There are different ways to do this:
Javascript OVerlay Types.
3rd party library (Piriti)
AutoBeans
RestyGWT (backend + GWT. See this tutorial)
Restlet has a GWT client (see this thread for more details).
GIN per se doesn't have anything to do with the communication with a REST API.
It's only responsible for dependency injection on the client side.
The translation of beans to JSON depends on the backend. Spring can basically automatically serialize Java beans into JSON using Jackson.
Evening all :)
I'm looking to create a Java web application. I envisage that it will use Spring web MVC and JSPs, however I would like to expose certain functionality as REST calls so I can create an android client.
Does spring offer anything to help me in this area? How can I keep the REST code and the web front end code separate yet not have to maintain essentially 2 versions of my application (one for the web, one for REST clients).
Not looking for spoon feeding, just some pointers of where I should start reading.
As others have mentioned, Spring has pretty good in-built REST support now. When combined with annotations, this allows really simple set-up of a RESTful API. Spring can be configured with different view resolvers, which can automatically respond with a different view of the data depending on the Accept header for example. So you could return either JSON or JSP automatically from the same data, see the ContentNegotiatingViewResolver. Your Controller and Model can then be common and implemented once, leaving the work in the View layer.
I've used this approach before to return JSON when the request was via AJAX and a JSP view built with the same data when accessed by a browser.
Jersey is a pretty nifty tool. It integrates well with tools like Spring, Guice, and Jackson to provide you a pretty seamless way to create RESTful resources.
Jersey is pretty simple, works well, and serves as the reference implementation to boot. Plus, it has some nice REST client support, much of which will probably make it into the JAX-RS spec.
In terms of marrying that with Spring MVC, I'd recommend you make sure you model your application so that you have facades (Service classes) that provide all the core functionality you need and then simply reference them as needed in your MVC code or REST code. You shouldn't be duplicating business logic
You can do this using Spring 3.0. Spring 3.0 came out with the ability to specify #PathVariables to pull values out of the URL path (previously this was not easy in Spring MVC).
You would also use #RequestMapping to specify the HTTP method(s) each method in your controller should respond to.
I've also use Spring Security to implement an API key type of functionality. This way you can restrict access to your API in a way that is easy for REST clients to implement. I had to extend org.springframework.web.filter.GenericFilterBean and add a the proper Authentication like this
SecurityContextHolder.getContext().setAuthentication(apiKeyAuth)
There's a new REST API in Spring 3.0 MVC:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://www.springsource.org/download
Apache CXF integrates well with Spring and offers many method for exposing services. From the overview section of the CXF homepage:
CXF helps you build and develop
services using frontend programming
APIs, like JAX-WS and JAX-RS. These
services can speak a variety of
protocols such as SOAP, XML/HTTP,
RESTful HTTP, or CORBA and work over a
variety of transports such as HTTP,
JMS or JBI.