We have few services on Google App Engine(GAE) and few on Google Container Engine (GKE).
The one on GKE is a sort of indexing service RESTful API and runs in background once triggered. It is an RESTful endpoint developed using Jersy.
my confusion and question is, Is migrating this to spring boot beneficial ? I see advantages of spring as DI, aop, exception handling etc. plus I have worked on it before inclines me more towards choosing spring :p
In contrast , if continue using jesrsy, we have to adopt guice for DI and I don't have much idea if we can do anything sort of aop and security (maybe using filters etc)
Please let me know your views/experiences on this.
Thanks In advance!
You don't necessarily have to use Guice if you keep using Jersey, Spring integrates very well with Jersey even before Spring Boot was released.
Spring Boot provides a Jersey starter that makes integration easier: spring-boot-starter-jersey
And if you are curious, I published a while back a post about Spring Boot, Jersey, Swagger and Docker
Related
So far I have seen examples for clients to use spring-webflux in spring boot 2 which has WebClient and WebTestClient. I've got consumers who still use Spring boot 1.5 and wants to use reactive services written in Spring boot 1.5 on the server. We can't upgrade our services to spring boot 2 due to third-party libraries we use. Looking for client examples which consume Flux APIs? Can anyone share the examples?
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 would like to build my own RESTful API Server and I have no idea what I need for that.
I'll tell you a bit about the project:
On a Webservice (www.mysite.com/) users can register and manage their account and so on. But they also can use the RESTful API (mysite.com/api/...) and can do there pretty much the same via REST.
What is a good way to realize that? Do I need to use jetty or something similar?
Should I split web service and restful api ? what I a good architecture for that?
Thanks :)
You can use Spring controller for building a restful server. You can run it on tomcat or jetty doesn't matter.
Check this url : http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch18s02.html
Tomcat and Jersey are easy to get up and running. I've had some issues with Tomcat 7 and Jersey, but with Tomcat 6 it was straight forward.
This tutorial is quite easy to follow. It's a bit old, but the principle remains the same.
IBM provides good set of information and tutorials about building RESTful web service with Java (Link). After getting your web service running, you can deploy it to Amazon. Take a look at AWS Elastic Beanstalk.
In 2017 one of the best solutions would be to use spring boot. Gives you great effects without writing tons of code.
#RestController
public class HelloController {
#RequestMapping("/")
public String index() {
return "Greetings from Spring Boot!";
}
}
I found a simple example at http://coder2design.com/rest-web-services/
to build a REST application.
XML Schema(xsd) is used to build domain classes.
Eclipse EE is used as IDE and Maven for building.
Jersey as a framework for REST
Hibernate for persistence layer.
MySQL as DB
All other configurations are nicely explained.
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.
I am totally new to Spring Web Services and so what concept should I start concentrating on and where should I be looking for them and in general what steps would you recommend to get to speed with Spring Webservices Module.
Note: I have an requirement to build Web Service for and consume Web Service from different application and I have never worked with Web Service in the past, I am looking at Spring WS option because both application are developed using Spring Framework, is this a good assumption to look for Spring WS or not ?
Any guidance and suggestion for discussion kind of approach would be highly appreciated.
Thanks.
(...) I am looking at Spring WS option because both application are developed using Spring Framework, is this a good assumption to look for Spring WS or not?
It's not a wrong assumption (bad integration between Spring WS and Spring would be a total irony) but you should not exclude other stacks on the fact your applications are using Spring. JAX-WS stacks (like Apache CFX or JAX-WS RI) provide Spring integration as well.
Personally, I like JAX-WS (that I use for contract-first web services) and, while it's hard to be more specific without more details about your requirements, I simply don't think that Spring WS offers any advantages over JAX-WS and I would probably go for Apache CXF in your case.
Maybe have a look at what others are saying in this previous SO question (please read all answers, the accepted one is not really good in my opinion).
What are your protocol requirements? Do you have to use SOAP, or are you free to use your own XML marshalling over HTTP (e.g. a RESTful approach)?
If you must use SOAP, then see this guide I wrote to Spring WS web services. If you're free to use your own lightweight RESTful web services, then see this example I wrote on RESTful web services.
I wouldn't use Spring WS ONLY because of the reasoning you provide. You need to identify more functional requirments like:
Can you use markup (JSON, XML, etc.)
Should you provide content negotiation
Do you need to provide complex objects (i.e. SOAP as james suggests)
Are you providing a RESTful service
etc.
I've worked with web services a lot in the past few years and there seems to be a few major projects for creating them:
Apache Axis (primarily SOAP)
Apache CXF (primarily SOAP)
Jersey (REST)
Restlet (REST)
There are other offshoots like Spring WS, or even Spring MVC, but you need to evalute which will work best.
Personally I use Jersey a lot, which also provides Spring integration. Jersey also has an awesome HTTP client for consuming services, but don't confuse creating a web service as being akin to consuming a web service. They are separate workflows and you could use separate third-party projects for both (e.g. Apache HTTP Client for consuming, and Jersey for producing).
Spring WS might work best for you, but my advice would be don't use it just because the other applications use it...use whatever works best and fulfills your requirements.