From REST to Repo

Recently I’ve been working on a feature for one of our products to enable it to communicate to ERP systems (http://en.wikipedia.org/wiki/Enterprise_resource_planning). These live in the client’s domain and typically they provide secure access for us to pull in information and data. From a user experience perspective, they want flashy things like autocompleting and filling in form fields from data pulled from these ERP systems. Here’s a breakdown of the major pieces that were built, with specific emphasis on the framework mentioned below (in which this post is focused on):

  • Extended certain input fields to have autocomplete functionality that fire off AJAX requests and receive back JSON with data used to populate the form. The jQuery UI Autocomplete plugin-in was used to accomplish this.
  • An intermediate or middle-tier which provides a well defined set of RESTful web service(s). These web services serve as the endpoints for the above mentioned AJAX requests. Each request is parsed and translated into a method call on a specific repository (all derived from the URL).
  • Repository implementations either deal directly with talking to the ERP system components or delegate off to other pieces that do the work. In the end, finding, saving data, etc all happen via the repository.
  • A web UI front end to navigate the ERP data and create, update, delete, etc.

My first pass involved simply creating a servlet that would examine the URL and invoke the appropriate methods. For example:

A GET /parts/name/RHS+Washer would translate to PartsRepository.getPartsByName(“RHS Washer”)

A POST /parts/name/RHS+Washer with the payload {item: “RHS Washer”, description: “A description”} would translate to PartsRepository.setPartsValuesByName(“RHS Washer”, Map representation of the JSON object)

At this point I was doing this by manually parsing the URL and invoking the method based on what was received. However, the requirements (and in the fact the nature of the whole ERP domain) would drive us to need something more flexible and dynamic. Something that would facilitate different entities and rapid development of the ERP interfacing/communication code. This need drove me to develop a framework that parses a RESTful URL, translates it into a method call on a repository/service/banana, invokes this method call and returns a JSON resprentation of it’s result (if applicable). The kicker: A developer only need create a new ‘Repository’ class prefixed with the entity name and the framework does the rest (including method lookup). There are no URL mappings to services or methods. Everything is by convention.

So instead of the development process being:

  • Create a new servlet (or Restlet, Jersey webservice) mapped to the new entity type
  • Translate the URL or annotate methods, declare through XML on a specific service/method
  • Write the implementation that does the work and invoke it

It becomes:

  • Create a repository or class named after the entity with a well known naming convention and implement it

Keep in mind this is still in it’s infancy. But I’ve worked on projects where something like this could have come in handy. I’m sure a language like Ruby or a framework like Sinatra might have something similar.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply