Spring Data has a native web support for Pageable send over the web, as parameters in HTML Query, through PageableHandlerMethodArgumentResolver.
I have not found JPA Specification executor for that, which from my point of view would be very useful.
Is there one?
The reason that there's no generic one available for you is that the predicates you build in it is completely depending on your domain model. A good example for how to use Specifications with Spring MVC can be found in the answer to this question.
Related
Why would one like to integrate JAX-RS(Jersey) using Rest API to Struts2? Struts2 is itself a mvc framework, so why would anyone want to integrate these both? If combined, how will the resulting framework be(I wanted to know if REST API just control the controller part of MVC).
There is a RESTful plugin called struts2-rest-plugin that has been included with the framework since version 2.1.1. A fair amount of information on the plugin can be found here.
Essentially, the plugin uses a custom action mapper that examines the request and based upon the HTTP Method used in conjunction with the URI, it dispatches the request to one of several different method names (e.g. GET /movies dispatched to index() method of action).
Just because Struts2 is an action-based framework does not mean a RESTful solution cannot be included as an alternative for developers. Spring MVC offers similar solutions themselves and it is also an action-based framework.
If you consider your JSON response as your view, you'll see that the fact that Struts2 is based on MVC design makes logical sense. Your model is simply the data structure you are returning to the client and your controller is the action.
Consider reading the link above on the plugin and you'll get a better picture of how the two can be integrated. If you want to return JSON but don't necessarily want to offer RESTful URLs in your Struts2 application, you can also consider the JSON plugin, found here.
I am not sure about Struts2, but in the past Struts1 did not have a "Rest" adapter built in. Jersey provides the cool #annotations that will easily serialize your datamodel and will push you in a "Restful" direction. Jersey does not provide an MVC framework as much as it provides convenience methods to work in a Restful/resource based way.
Spring REST Docs was released recently and the documentation says:
This approach frees you from the limitations imposed by tools like Swagger
So, I wanted to ask when Spring REST Docs is preferable to use comparing to Swagger and which limitations it frees.
I just saw a presentation here that touches on your question among other topics:
https://www.youtube.com/watch?v=k5ncCJBarRI&t=26m58s
Swagger doesn't support hypermedia at all / it's URI centric
Swagger's method of inspecting your code can lag behind your code. It's possible make a change in your code that Swagger fails to understand and won't process properly until Swagger gets updated.
Swagger requires lot of annotation, and it's painful to include the descriptive text you want in an api document in annotations.
There are just some things that Swagger can't figure out from inspecting your code.
In any case, these are just a couple of points. The presenter does a much better job discussing it than I could.
I thought I would chime in to give a little bit more context surrounding Swagger, what it is, and what it is not. I believe this might help answer your question.
Swagger 2.0 is being adopted by a lot of big names and big platforms like Microsoft Azure, Paypal, SwaggerHub.com, DynamicApis.com, etc... Something to keep in mind is that Swagger is very simply a specification. It is not a framework. There are a lot of frameworks out there built to generate Swagger output that crawl through your code looking at your API information in order to build the Swagger 2.0 JSON file that represents your API. The Swagger UI that you see your APIs on is driven directly from this Swagger 2.0 JSON file. fiddler it to check it out
It is important to note that a framework that was created to allow you to "use swagger" is not how Swagger has to work (i.e. it is completely up to the implementation of the 3rd party framework). If the framework you are using to generate your Swagger 2.0 documents and UI is not working for you then you should be able to go find another framework that generates the Swagger artifacts and swap the technologies out.
Hope this helps.
From Spring REST docs:
The aim of Spring REST Docs is to help you to produce documentation for your RESTful services that is accurate and readable
This test-driven approach helps to guarantee the accuracy of your service’s documentation. If a snippet is incorrect the test that produces it will fail.
Spring REST docs advantages:
Documentation is written in the test code so it does not overload main code with lots of annotations and descriptions
Generated docs and examples are accurate because related test must pass
Docs can provide more specific and descriptive snippets
Format is suitable for publishing
Spring REST docs disadvantages:
Requires more work
Documentation provides request/response examples but don't provide interactive tools to modify and try out requests
Swagger advantages:
Quick, automated generation from a code
Interactive request execution - can be used for acceptance testing
Built around the OpenAPI Specification
Swagger disadvantages:
For more descriptive documentation it will require a lot of annotations
Tests are not related to the documentation so sometimes documention may deviate from reality
There is some limitation with swagger and the specific spring stack.
For example : with "param" in your Request Mapping you can define more than one method with the same url ans so simplify your code.
But swagger show you just one method
One disadvantage with Swagger is: it cannot handle models which have cyclical dependencies. If a model has cyclical dependency and if swagger is enabled, then spring boot server crashes.
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.
In short, how do you transfer semantic data between client and server with GWT and which frameworks do you use? Read on for more details that I've thought about.
For example, using GWT 2.2.0 features like the RequestFactory will bring the constraint to have java beans transferred while the semantic resources are represented as triples and a resource can have a varying set of properties. So the RequestFactory itself cannot be shaped to transfer semantic-driven data easily.
A way to do that would be to use RequestFactory with beans that represent triples. Such bean would have 3 properties: subject, predicate, object. These beans will be transferred to client which will know to query, change their properties and then send them to server. This approach will however need a custom implementation(there are no GWT-based frameworks to represent semantic data on client-side, from what I've searched so far) and that could prove buggy or unoptimized. I've seen this approach in this project: http://code.google.com/p/gwt-odb-ui/ - it used GWT-RPC and implements some classes that represent semantic resources. However, I think it's in an incipient stage so I'm reluctant to copy their model.
Also, I've found that Restlets is a framework that supports the semantic web approach to applications. However, there is no documentation or an example on how to use Restlets with Semantic Web and perhaps with GWT. Also, Restlets is also supporting GWT. Does anyone know if this is a viable solution or not?
Thank you!
Restlet should work quite well for you. It has a GWT edition able to automatically serialize your triple beans. In addition, it also comes with an org.restlet.ext.rdf extension, including a Link class similar to your triple bean idea.
For further documentation, I would suggest the "Restlet in Action" book which covers GWT and the semantic web from a Restlet and REST point of view.
I have been trying to figure out how to use JAX-RS for quite some time. I started from the very basic concepts and then to gradually understand the annotation styled programming, the meaning of #Path, #Get, #Post, etc.
To my understanding, as to what has been mentioned in a lot of places, JAX-RS is a framework that focuses on applying Java annotations to plain Java objects (Page 27, Bill Burke, RESTful Java).
I have then got confused beyond this point. If JAX-RS in itself is a framework that defines APIs dealing with annotations in order to implement RESTful web service, what's the meaning of "implementation of JAX-RS" such as "Jersey" and "JBoos Resteasy". Another layer on top of JAX-RS? Why do we need them?
Could someone provide me some insights about it? Many thanks!!!
JAX-RS is a standard defined in Java Specification Request 311 (JSR-311) and Jersey / RESTEasy are implementations of it.
Being implementations mean that the spec says "if you put #GET("/foo") on a method (bar()), you may access data X" - now in an app server, someone needs to go in and actually read your deployed code, parse the byte code with the #GET annotation and then if the user actually browses to e.g. http://localhost/foo get this web request to reach bar() and translate the return value of bar() into a http answer (e.g in XML or JSON representation).
So the spec with the name "JAX-RS" only provides the syntax and semantics of e.g. #GET, but the work of parsing requests, calling the right methods, marshalling the result values etc. need to be done by a package that implements the Spec.
Work on the version 2.0 of the standard has started as JRS-339.
See also http://en.wikipedia.org/wiki/Jax-rs
JAX-RS is a specification for RESTful Web Services with Java. There is a reference implementation that is included in Java EE but since it is a specification, other frameworks can be written to implement the spec, and that includes Jersey, Resteasy, and others.