I would like to use RESTful services in a CDI/JSF2 application. I am not very familiar with JAX-RS however I have read that its lifecycle does not play well with CDI/JSF2. Is it possible to incorporate JAX-RS with CDI/JSF2 in a JEE6 stack? If not are there alternatives?
thanks
You can use JAX-RS just fine along side a JSF application, however, they don't play well together. For instance, you can't use JAX-RS to have "http://localhost:8080/story/92/" return a JSF page with a Story entity with ID 92.
You can, however, use PrettyFaces to do something very similar to this.
JAX-RS makes sense for non-JSF resources. "http://localhost:8080/story.xml" makes perfect sense for JAX-RS.
You can call your rest services from your JSF templates. For example you can run your rest services from http://localhost:8080/services/ while your JSF page is returned on http://localhost:8080/index.xhtml. You can then write some custom javascript to call your rest services from your JSF page. This is actually the general practice with REST services so they can be consumed by many different UIs. JSF may not be the best for consuming REST services, but it is possible.
Related
I've started to use GWTP framework. And I've noticed that it has his own implementation of Rest comunication. I've used to use GWT with RestyGWT And Spring server.
Now I wonder- can I use GWTP Rest Dispatch with Spring server?
Or should I stick with RestyGWT (which is not a part from GWTP).
I haven't found a word about it in official documentation of GWTP. And the example given have in shared package rest service interface, which is implemented on server side. Please help.
You can definitely use Rest Dispatch with whatever backend you like. Take a look at this tutorial if you'd like more information on how to setup Rest Dispatch. This tutorial was also tested using the Python webapp2 web framework as backend.
GWTP REST Dispatch just calls REST URLs, so it doesn't care which implementation is behind the URL, as long as it's reachable by it and returns a proper response. So yes, you are totally fine to use Spring MVC, JAX-RS or anything else for your backend.
im using spring MVC and webflow to create a game server and serve some web pages to the users. Thing is, the javascript game will also make multiple ajax calls to restful services on the same server for some game logic. While the web page serving performance is not critical, the restful service calls need to be as efficient as possible (efficient as in response time).
For performance of the services, would it be better to use pure JAX-RS (jersey) web service calls without the spring ws overhead (since i understand the spring layer could affect performances negatively) or would it be the same if i used the spring webservices framework instead and maintain integration with the rest of the spring family?
thanks!
There aren't many clear benchmarks out there, but take a look here:
http://www.techempower.com/benchmarks/
It clearly shows the overhead of using Spring. Compared to Servlets that serve JSON manually Spring is "slower". Personally, I don't think that Spring cuts development time, unless you are very much familiar with it. Creating a simple servlet that will act as a REST API is very simple. Take a look at the servlet code from the benchmark:
Servlet benchmark
I don't think Spring per se will affect performance negatively. Where did you hear that?
Spring web services are "contract first" SOAP services. If you're saying that you don't want to pay the overhead of SOAP, XML, marshalling and unmarshalling, then you have a valid point. That's true whether you use Spring to implement the services or not.
REST is HTTP, so it's a natural for AJAX calls.
I believe Spring 3.0 supports REST, so it's not a "Spring or not Spring" choice:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/new-in-3.html#d0e1188
I develop a CRUD Spring, Servlet/JSP application. I will develop a desktop Swing application with same functionality. My question is that possible to communicate and resuse servlets on swing application (not applet)?
Yes, by making http requests. You can do them with multiple tools. Two of them:
new URL(..).openConnection()
apache http components
since you tagged spring, if you are using it with swing, you can use its RestTemplate. It's used to invoke restful services. You can expose your logic as restful services through the servlets (or spring-mvc), and consume them with RestTemplate
The Rest idea above is pretty good. In fact, by using Spring and it's proxies, you could use any kind of webservices (RESTFul or WSDL), and Spring would make it transparent for you.
Please check some examples in the Spring manual. Take a look at how to create proxies using service interfaces.
Best regards.
since its all via HTTP, and mechanism as suggested above can work.
Or you can even open bytestream to the server and read/write using that stream.
I have a question regarding RESTful client implementation.
At this moment I have developed the server using RESTeasy and EJB. Method return JSON in much case. And now we are starting backend development(WEB). And can't select a framework for this, that supports authorization, authentication...
Could you suggest a pattern, framework, approach etc..
If you looking for a Java web framework that fits your existing technology (EJB) you should take a look at JSF and WebBeans (note though that JSF does not expose RESTful URLs for its actions/controllers).
However since you also mentioned REST I guess you just want a backend framework for your services that can handle user security and auth. In this case you should take a look at spring (in particular spring-security and spring-web). Most JAX-RS implementations have good support for spring, although I should mention that spring itself has a splendid REST framework that of cause works very well with their other offerings.
If on the other hand you want a framework that can handle security in the context of a EJB application that exposes a RESTful service, then you are in a tough spot. RESTful applications are meant to keep most of the state at the client, in contrast to most EJB apps that frequently uses state-full session beans. You can integrate JAX-RS with stateless or singleton EJBs and then either use spring-security to handle the security/auth or use the <security-constraint> in the web.xml as described here
JAX-RS has some MVC support, but I wonder if JAX-RS is really a good choice to build web application for human use.
If a user enters wrong or incomplete information in a form, it should be displayed again like with Grails or Wicket. Is there a comfortable way to do this with JAX-RS?
As far as I know the URI mapping doesn't work correctly, if not all required parameters are given or there are type conversion problems (with Date for example). Is that correct?
Is there support for internationalized templates?
Here is an example for a simple JAX-RS based GUI application. But it is really simple and thing like i18n and validation are not discussed.
Yes you can, but you have to clear your head of the old page-post model and start to think of your application as a disconnected UI that communicates with a RESTful SOA. When form data is entered, it post to a service endpoint if the data is not correct then you respond back with an error and the UI handles dealing with that error. You do not post forms to the server in the traditional page-post model but rather you make RPC like calls to your back end system. Your view becomes completely detached from the rest of MVC stack. This makes replacing the view with a custom mobile or IVR system extremely simple.
If a user enters wrong or incomplete information in a form, it should be displayed again like with Grails or Wicket. Is there a comfortable way to do this with JAX-RS?
With a rich internet application you do not have to repopulate data because you never left the page, an XHR call is made to the server and either a success 200 is sent back or an error. The UI then decides what to do based on that response, but the page is still intact because the call was out of band from the main UI thread.
JAX-RS is the Java EE RESTful framework. JavaServer Faces (JSF) is the Java EE MVC framework. It supports all what you've mentioned in your question: postback to same form on error, i8n/l10n and much more. To learn more about JSF, go through Java EE 6 tutorial part II chapters 4-9.
You can do a bit MVC with JAX-RS, but it isn't a full fledged MVC framework. The same story goes on that you can do a bit RESTful with JSF, but it isn't a full fledged RESTful framework.
If you want best of both worlds, I think you really need to head to Ruby on Rails or Groovy on Rails.
Or take the integration approach to get the best of both worlds: JAX-RS + MVC.
The JBoss RESTEasy implementation of JAX-RS integrates with Spring MVC. See http://www.jboss.org/resteasy
Here's a little tutorial on RESTEasy + Spring MVC: http://java.dzone.com/articles/resteasy-spring
There are lots of questions in this one, I'll give my view on two of those.
"I wonder if JAX-RS is really a good choice to build web application for human use."
Web services are usually for machines to interact with, although I would argue it is usually humans that have to programme the interactions - this needs to be compared with SOAP where, at the moment, there is much more scope for machine generated code from WSDLs.
"If a user enters wrong or incomplete information in a form"
then in a RESTful HTTP web service which accepts a html form representation you should return HTTP error 400 because the client has provided a representation that does not conform to the representation your service expects - it is up to the client to deal with the error.
Take a look at ReXSL - it's an MVC framework, on top of JAX-RS. Thus, the answer is - yes, JAX-RS is perfectly suitable for MVC design.
Short answer: YES.
It serves as the base to implement MVC (MVC 1.0 - JSR 371) for JAVA EE 8. The Controller will be a JAX-RS bean with #Controller annotation (on class or methods).
For mor information see: MVC 1.0 (JSR 371)
If you took that path at your time you've done a really good decision, it should make it easier for you to upgrade and use the new Java EE 8 MVC architecture.