We are about to take on a large project implemented in Grails (2.3.7). The application makes heavy use of many different (end-points as well) REST-ful webservices. We are of course interested in using what is considered to be "best standards" (at least currently).
We are currently considering:
- Using the Groovy HTTP-builder
- Using the "REST Client builder" plugin
Any other we should consider and what are your experiences using the above mentioned?
I have used both http://grails.org/plugin/rest and http://grails.org/plugin/rest-client-builder and both provide a nice wrapper around HTTP Builder library. The "rest" plugin provides dynamic methods for you if you like using that syntax. I prefer REST client builder though. Both are easy to work with.
Related
I've just started on a small project to create some REST services using Google App Engine and Java. I'm new to both technologies, but I've done some reading on both. I'm familiar with SOAP (have used them previously), and I think I understand the conceptual differences between REST and SOAP.
Currently I need info regarding two things:
1) I'm trying to find some tutorial which builds a simple REST service from scratch for deploying on Google App Engine (GAE). The simpler the better, but it should have at least a few routing options. I don't need any UI, if that matters.
2) Which RESTful Framework should I use with Google App Engine. Again, simplicity is what I'd like, and something which has tutorials and a newcomer can easily grasp.
My ultimate goal is to just write a REST wrapper with multiple routing options, which eventual consumes some pre-existing SOAP services and returns their results.
Have you checked out Google Cloud Endpoints for creating a REST service? Its pretty simple and straightforward, also has support for OAuth.
I would give Jello framework a try. It offers a clean, and simple to follow, JSON format and provides a very powerful and comprehensive RESTful implementation that follows the OData specification.
Here is Jello's REST development guide: http://jello-framework.com/guide/rest.html
I am deciding if I should learn Groovy and Scala, and currently I am comparing web frameworks. I like the Groovy language a bit more, but Play! works with both Java and Scala. Another thing pointing me towards Play! is the tight CoffeeScript Integration. For collaboration purposes, I need my framework to be able to affectively communicate and interact with some sort of JavaScript. For my choice I have a few questions on the Grails frameworks.
Questions
Can Grails use Java, or just Groovy?
Does Grails have any tight JavaScript integration? I mean can the two technologies communicate at runtime?
The Eclipse Grails Project seems to be maintained by spring. Does this mean Groovy can use Spring?
I am still confused on which to learn. Hopefully the answers to these questions will help me decide which to learn.
All of this information is widely available on the internet, easily found using Google or your favorite search engine. That said, here are the answers to your questions:
Question: Can Grails use Java, or just Groovy?
Answer: Grails uses both. Groovy is a dynamic language which runs within the JVM and in a lot of ways extends Java. Grails uses both Java and Groovy. You can use both within your Grails project as well. This allows you to leverage the vast array of Java libraries available. Much like Grails itself does.
Question: Does Grails have any tight JavaScript integration? I mean can the two technologies communicate at runtime?
Answer: Any Javascript library can be used, and they can (if you make them) communicate at runtime. (Your question doesn't really make a lot of sense). In regards to coffeescript (which you mentioned in your question), there are plugins available that will compile coffeescript at build time for your Grails project.
Question: The Eclipse Grails Project seems to be maintained by spring. Does this mean Groovy can use Spring?
Answer: Grails is built upon Spring, so yes. You (and it) can use Spring. There are a great number of reasons to leverage the Spring framework within your Grails project, and with the Bean builder DSL it's fairly straight forward to do so.
Matt Raible has a great comparison of all the JVM frameworks. I suggest checking out Play and Grails within that comparison to see how they rank in the broader comparison...
http://www.slideshare.net/mraible/comparing-jvm-web-frameworks-february-2014
You can very well use Java in Grails framework. There are two options:
1. Grails has a separate source folder for Java - here you can use Java classes
2. You can also use Java code inside a Groovy classes
Grails uses Spring and Hibernate
Try both out. Choosing a web framework is a big decision and it's worth spending some time choosing.
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/
For a college project i'm thinking of implementing the business layer in Erlang and then accessing it via multiple front-ends using REST. I would like to avail of OTP features like distributed applications, etc.
My question is how do I expose gen_server calls/casts to other applications? Obviously I could make RPC calls via language specific "bridges" like OTP.net or JInterface, but I want a consistent way to access it like REST.
As already mentioned Yaws or Mochiweb are a great way to go but if you'd like a dead simple way to get your RESTful API done quickly and correctly then use Webmachine. It's a layer on top of Mochiweb that implements proper HTTP behavior based on Alan Dean's amazing HTTP flow diagram and makes it easy to get REST done right.
I'm using it right now to expose a REST API as well as handle a COMET application and it's been pretty easy to do, even for an Erlang newbie such as myself.
I did something similar for my job and found it best to use REST to expose the business layer because even Legacy languages such as SoftwareAG's Natural is able to access it. The best mechanism that I have found in Erlang is to use Mochiweb.
You can find more information about using it from the screencast located at
Erlang In Practice Screencast. Episode 6 is particularly helpful but all of them are excellent.
A resource to walk you through installation is How To Quickly Set Up Ubuntu 8.04 loaded with Erlang, Mochiweb and Nginx and Migrating a native Erlang interface to RESTful Mochiweb (with a bit of TDD) provides a good start if you don't find the screencasts to your liking.
The HTTP flow diagram link is dead. The original version and a updated version created in collaboration between Alan Dean and Justin Sheehy ist also hosted in the Webmachine project: link to latest version of the HTTP Diagramm.
There is valuable approach to design gen_server calls/casts in flavor of REST if possible. You can use messages as
{get, Resource}
{set, Resource, Value} % aka PUT
{delete, Resource}
{add, Resource, Value} % aka POST (possible another names are append, modify or similar)
Then its mapping is easy. You can make some transformation URI->RESOURCE or use identity. For most of your application this should be wort approach and special cases you should handle specially. You can think there will be big margin, where you can't use this approach, but this should be mostly premature optimization.
Do you really mean a RESTful interface or RPC over HTTP? Building a RESTful interface on top of an existing layer is more work than just exposing existing methods via HTTP.
I'd suggest to use mochiweb or yaws to implement a (generic) rpc layer.
Just an update, Webmachine has moved to bitbucket: new link to Webmachine