I'm trying to build a REST web service (server side) that will allow a partner system to connect/POST order information in JSON format. Should I use JAX RS (for example from JBOSS RESTEasy) or Spring MVC to build such a service? They both seem capable enough to accomplish the same thing as far as building a REST service is concerned.
Thank you!
Depends if you want to learn something new or go with what you already know.
If you already have experience with Spring MVC and want to get the work done quickly, then I'd suggest staying with Spring MVC. There are some neat enhancements to the REST features in Spring 3.1, including the ability to generate "end point documentation".
If, on the other hand, you are looking to expand your CV and/or enjoy learning new technologies, then give JAX RS a go. I haven't used it but it is a dedicated WS framework that would likely have any feature you'd require.
Of course, if you have experience with JAX RS but not Spring MVC, then the opposite applies :-)
If you are developing an EE 5 project then I would recommend using JAX-RS with Spring. The RI for JAX-RS, Jersey, has a Spring JAX-RS dispatcher servlet. This makes it much easier to manage dependency injection with JAX-RS and gives you all of the Spring MVC features like form binding and validation, but you are also able to use the Java standard approach for REST - and in my opinion, a better and easier to manage approach than Spring REST.
If it is an EE 6 app, then you may want to think about ditching Spring as JAX-RS is part of the EE 6 specs and you can use EE CDI within your JAX-RS classes.
Notice that Jersey has a bug that affects its integration with Spring:
https://java.net/jira/browse/JERSEY-2301
In summary if you need Spring AOP in your JAX-RS resources it will not work. Dependency injection works well.
REST is more of an architecture style of developing web services which are very easy to understand without even documentation for a developer. Normal tech savy people can easily understand the URL patterns also the response types of JSON and XML support makes it easy for integrating with new javascript modularization standards such as backbone or angular.js.
On the other hand SpringMVC is more concentrating on model-view-controller architecture style of developing applications.
Related
We are making a web based application in Java that should be accessible to any device and so we zeroed in for Restlet for our REST based web service need.
For UI we are thinking of Freemarker together with Twitter bootstrap and database will be mongoDB. And guice for dependency injection.
Since I am new to most these technology stack, do you think this is fair choice for a long run. Also, for database mapper framework we decided to use Jongo it seems lightweight. Kundera is an option but it has lots of dependency. What you expert say ?
"Kundera is an option but it has lots of dependency." Not sure what do you mean by this statement? could you please explain it more?
Please take a look at https://github.com/impetus-opensource/Kundera/wiki/Kundera-Mongo-performance for performance using Kundera!
It really depends on your needs
REST Framework :
IHMO you should test at least theses 3 JAX-RS Frameworks : RestEasy / Jersey / Restlet and choose the one according to your needs.
JAX-RS Frameworks
https://stackoverflow.com/questions/1710199/which-is-the-best-java-rest-api-restlet-or-jersey
UI :
I've worked with Jersey + Freemarker through a framework called Webengine from Nuxeo, it was ok.
Nevertheless, you should consider a rich client approach based on Javascript/CSS/HTML (see Backbone.js, Ember.js)
Pros :
With such approach you could expose JSON REST services using a JAX-RS Framework (instead of freemarker/html services) .
Theses services can be consumed by a web application and/or native mobile apps (ios, android).
Cons:
Your team must have advanced javascript skills (this blog can help )
Database :
What kind of data do you need to store ?
MongoDB is document-oriented and flexible enough to cover lots of needs
As you said, Jongo is a lightweight API (500 lines of code + 1 dependency) over mongo-java-driver.
It allows you to query MongoDB as if you were in MongoShell (ie. with plain json/bson queries) and map your object using jackson.
This question is a good example: Mongo DB query in java
Relying on Restlet Framework for your RESTful web API/service backend sounds like a good choice for a multi-devices application. FreeMarker is very powerful and flexible so you should be in good company there as well.
I don't know too much about the other pieces of your stack.
I want to use EJB in my GWT Application, but I coulnd't find a current Tutorial. I am new to the topic of EJB's and with GWt I have worked the last months. At the moment I have got some RPC Calls in my GWT Application and this works. Is it's possible in GWT to use EJB and if yes would it be difficult to install?
GWT is a client-side framework. It can connect with the server-side i.e. using RPC calls, REST web services or SOAP web services. An EJB on the other hand is a server-side technology which can define several entry-points for its clients.
I would consider creating a proper business logic and create a boundary for it - in form of i.e. RESTful Web Services. This functionality can be tested in well-controlled environment or even in real-life application server.
If this is done, than you just need to create a regular GWT application which 'talks' with EJBs through REST-WS.
Sorry, but I'm not aware of any tutorials about GWT + EJB. There is an example of EJB RESTful implementation at Adam Bien's weblog, but if you're really interested in EJB technology and don't know a bit about it, I would recommend to take some decent book first, like Enterprise Java Beans 3.1.
For example, Play-framework supports RESTful services like this: RESTful on Play! framework
How does this compare to something like Jax-RS Jersey implementation? Does a framework like Play run circles around Jersey because of all it's cool bells and whistles, and it does REST too?
Developer productivity is important, but so is a proper implementation. Perhaps using an MVC framework for REST only services is 'wrong'?
Note, only RESTful services, no UI components at all.
Even though it's not "wrong" to use an MVC framework for RESTful services, there are some pros and cons versus using a JAX-RS implementation.
(Disclaimer: I have only used Jersey and Play! for fun, and not on production-grade systems, so I have tailored my comments more generally to MVC vs. JAX-RS. Keep in mind that these are broad generalizations.)
MVC frameworks--at least the ones that are considered developer friendly and "slick"--typically save you from having to build a persistence layer (the model part). Most also simplify "routing" requests using either scaffolding via convention or some form of configuration. The downsides are that you have to conform to some conventions for your controllers and usually have to write a view for each resource (or build layers of abstractions to avoid rewriting the same code).
JAX-RS excels at defining the routing (using Java annotations) as well as eliminating any restrictions on the service class. In my experience, that has greatly reduced the amount of boilerplate code and developer overhead. Jersey and Apache CXF also handle the XML or JSON serialization using JAXB annotations, which eliminates the need to figure out the view in an MVC context. The downside here is that you have to figure out your own ORM or persistence layer, which could be good or bad depending on whether you're building on top of existing data or creating a greenfield system (or using something other than an JPA/RDBMS e.g. NoSQL data store).
My own personal comment: Play! is a really cool framework, but I'd choose CXF (or Jersey) over an MVC framework any day for building out a RESTful service. In my experience, this frees up the developer to focus on the logic needed for the service, and opens up options for different database approaches. Right tool for the right job.
As a rule of thumb: For Scala, use Play. For Java, use Jersey.
You can use Jersey/Scala and Play/Java; I've done both. It works. It isn't bad. But unless you have a particular reason to do that, I wouldn't mix ecosystems. Java and Scala are interoperable but they have different ecosystems, I would avoid adding Java-isms if you are using Scala or Scala-isms and dependencies if you are running straight Java.
Jersey and Play are generally close for REST services. Neither really has any killer features over the other.
Jersey defines URL mappings in annotations, Play defines them in a service wide route file. And they bundle or have varying quality of integration with different libraries for things like XML, JSON, database, testing, mocking, dependency injection libraries and app server deployment.
The Java world has JMS, Spring, JUnit, jdbi/hibernate/jpa, Jetty/Grizzly. The Scala world has Akka, specs2/ScalaTest, Anorm/slick. Jersey is a better fit for the first world, Scala for the second. You can definitely cross that, but it will be a little less elegant and might require more glue coding.
JAX-RS is a standard and implementations can be created by different vendors. Jersey is one such implementation. The other frameworks may make use of JAX-RS but are not standards. So it is not a one-to-one comparison.
I have never heard of Play before but it does look interesting, more akin to Rails and Django than Jersey. What I like about Jersey is that it can be integrated into existing Java web applications by simply adding the JARs and declaring some things in the web.xml. What I find confusing about Jersey and JAX-RS is the routing.
Play seems to make routing easier, however, correct me if I'm wrong, seems like it is an all-or-nothing framework and cannot be used alongside other servlets in the same web application.
I am asking this question because, I see that Roo include SPRING MVC and GWT...but
- GWT (on its website) shows an example of a MVP pattern but I think it is not comparable with the SPRING MVC framework (indeed Spring MVC has more features. I have never used it...but I read that it helps a lot to do website, and easily lets have a REST architecture (how to do as easily a REST architecture with GWT and a MVP plateform ?)...
Can you help me to choose between these technologies (taking care that I want to develop my app on GAE, and I will also want Mobile phone version) ?
I suggest you not to use GWT with Roo, its GWT support extremely buggy at the moment. (Saying this as a big fan of Roo)
Also, REST is architectural style which embraces HTTP as an application protocol, not only as a transport protocol, meanwhile GWT is a framework, or rather a toolset for creating rich web application which use JavaScript as a frontend, one has basically nothing to do with the other. You can however use Spring MVC to build RESTful applications:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch18s02.html
http://www.oudmaijer.com/2010/01/16/spring-3-0-rest-services-with-spring-mvc/
recently, i was research about which framework to learn.
I realize that request based component is mostly used in industry and has its own advantages because of its scalability. Moreover, there are some forumer that mentioned learning of component based framework(Standard Java API/framework/JSF) is waste of time(Is this true ?). On the other hand, customization in component is quite difficult but require to write less code.
My Question :
Which request based framework is compliant to Java EE 6 ?
Do ejb exclude from spring ot strut ?
Which framework has higher level and yet powerful and flexbility, performance ?
How to create UI in spring ? There are some people who used struts for front end and spring for back end or use spring alone.
Is correct to say that there is no HttpServlet anymore and instead of replace by action or something else.
Please help.
Thanks.
i would go es neat to java standard as possible, so look at ejb3/jpa for persistence and jsf2 for front end.
in a jee6 environment you can completely forget everything about struts and spring...
and of course there is still a HttpServlet, most of the web front end technologies are based on Java Servlet Specification.