Skip to content

Java REST API Framework Options

resting photo
Photo by shioshvili

I’ve been working with a couple of REST API solutions that exist in the Java tech stack.  I haven’t seen any great analysis of REST API solutions (though Matt Raible does mention some in this exhaustive slide deck about Java frameworks [pdf]), so wanted to share my on the ground experience.

First up is restSQL.  This framework makes it easy to get data from a database to a JSON or XML REST API and back.  If you have a servlet container available, you write two configuration files, one with a SQL query and one with db connection information, and you have a RESTful API.  For prototyping and database access, it is hard to beat.

Pros:

  • Quick to set up
  • Only SQL knowledge is required
  • No programming required
  • Allows simple mapping of db table to resource, but can include one to one and one to many mappings
  • Supports all four REST operations out of the box
  • Supports XML as well as JSON
  • Is an embeddable java library as well as a standalone framework
  • Project maintainer is engaged and the project is moving forward

Cons:

  • Requires a servlet engine, and you have to restart it for changes to your configuration to be picked up
  • Output format has limited customization
  • Only works with mysql and postgresql databases (though there is some experimental support for Oracle and MS SQL)
  • Doesn’t work with views
  • The security model, while fine grained, isn’t modern/OAuth (can be solved with an API gateway (like 3scale, Tyk or ApiAxle) or proxy

The next framework I have experience with is Dropwizard.  This is a powerful framework that creates uberjars that you can run on any port as a standalone service.  It’s not limited to providing a JSON representation of database tables–if you can create a Java object, Dropwizard can serve it up as a JSON resource.

Pros:

  • Community support
  • Extreme output formatting flexibility, but be prepared to write a custom deserializer if you want to handle anything other than reads of custom formatted objects
  • Supports any database that hibernate supports
  • Built in testing support
  • Brings together ‘best of breed’ tools like Jersey, Jackson and Hibernate, so you don’t have to do the integration yourself
  • Great documentation

Cons:

  • Have to roll your own deployment solution (tarball, chef, puppet)
  • No services startup script provided
  • Shading can slow down development
  • Not yet at 1.0 release

The last one I don’t have familiarity with, but a colleague used it in the past.  It is Sparkjava.  This is a lightweight framework that fits when you have an existing Java library with functionality you want to expose.  I’m not competent to write pros/cons for this framework, but wanted to mention it.

The gorilla in the room that I haven’t had experience with (in terms of writing RESTful webs services) is Spring.  I would definitely include this in any greenfield solutions review.

APIs Databases Java | moore |

5 thoughts on “Java REST API Framework Options”

  1. g00glen00b says:

    I didn’t know the other ones, but I really like the Spring Data REST framework.

  2. Jeremy says:

    Spark Java (which is now super confusing because of Apache Spark, the cluster computing framework from apache) pros and cons kinda break down like this:

    Pros:

    Functional
    Easy to pick up, especially for those familiar with Sinatra style microframeworks
    Small docs
    Extensible
    Java 8 lamba goodness everywhere
    Easy to get started
    Error handling
    Approachable code base

    Cons:

    Not a huge community (granted, I never really had to look for one. I didn’t have any issues. But there’s a mailing list and an IRC channel)
    Doesn’t update often
    Small docs
    Not a huge focus placed on speed

    I use spark for very simple web server tasks. Tasks I think most devs would just reach for Sinatra/flask for. But Spark gives me that level of rapid development while also running on the JVM.

    It’s important to note that spark has a bevy of features I didn’t even touch. Templates, customization requests and responses, etc. But I think the fact that I never had to touch 90% of the feature set of a very tiny http framework makes it very suitable for writing APIs.

  3. moore says:

    Thanks Jeremy! Nice summary. When I mentioned spark to a friend, he had exactly that confusion. Major bummer to have two projects using the same name.

  4. moore says:

    googlenoob, what did you like best about Spring for building REST APIs?

  5. Pingback: Dropwizard vs Spring Boot | Dan Moore!

Comments are closed.