3

I'm working on the backend of a java web application. We have a document repository (Fedora Commons specifically) where we house xml files. I want to abstract the API of the repository internally so that we aren't tightly coupled to one product. I'd also like to give the flexibility of connecting to to a repository via Java RMI or REST APIs. I was hoping to get advice or resources on how to implement something like this.

My thought it that I'd have some abstract repository class that had methods like getRecord, updateRecord, and deleteRecord. In the constructor I would pass the URI for the repository and the API method and port. This would allow some flexibility in the future so that if the REST api became more practical, but allow the flexibility or using RMI which could (should?) have better performance.

Am I over thinking this or am I on the right path?

Improve this question

3 Answers 3

Reset to default
3

Take this advice for what it is worth, but I strongly urge you to reconsider the use of REST API instead of Java RMI.

Without having solid metrics to compare, I would highly suspect that performance between Java RMI and REST would be similar.

  • Java RMI is an older technology which is not as widely adopted.

  • More Java developers likely have experience with REST and web services versus RMI.

  • Clients of your server are tied to Java technology (think expansion to mobile clients for instance)

  • Security concerns

These are just a handful of the issues with it. Beyond that, having to debug poorly written legacy RMI applications was a horrifying ordeal for me that has mentally and emotionally scarred me for life. That may make me a little prejudiced.

Improve this answer
1
  • +1 REST is more widely adopted, easier to code against, and in the end you want to support the least amount of wrapper/API code possible while still having the option of swapping out the 3rd party stuff.
    – Kevin
    Apr 14, 2012 at 17:37
2

I think you are on the right path.

There is nothing wrong with putting an abstraction layer on top of a third party API. Actually it is a very good idea. At some point, you may want to replace that API with another third party API, and you would only have to change your abstraction layer, instead of your entire application.

Now admittedly this is an ideal scenario. The truth is that you'll probably end up locked into that vendor for other reasons. But, you should still design this way anyway as it is good practice.

Improve this answer
2
  • 1
    One abstraction on another on another can lead to horrendous complexity. I would counsel against this approach simply because API design is very hard to get right. While you may succeed in abstracting one part of the underlying API, making your API so flexible that an entirely new API can be slotted in beneath it without changes (or even minor ones) is going to be tough. However, using a purpose-built decorator API such as JPA or JAX-RS is a good choice to avoid vendor lock-in - just don't roll your own.
    – Gary
    Apr 14, 2012 at 15:04
  • I think it depends on what you are doing. Obviously you wouldn't re-write a whole API. But the chances that you would actually use every feature a vendor API has is pretty slim. So, you can wrap what you are using and ignore what you aren't. This is especially helpful if the vendor API is complex or archaic. You can minimize your interactions with it, which is handy when these interactions can be error prone.
    – Alan Delimon
    Apr 18, 2012 at 18:17
1

Consider using OData and REST for exposing data

There is a lot of useful information on the OData website regarding how to expose data that any OData compliant client can interpret and use. OData is based on internet standards like AtomPub, JSON, XML etc and provides a collection of useful guidelines on how to structure URIs and so on. OData clients exist for Java, iPhone, PHP, Python, C# and many others so you won't limit accessibility to a specific programming language.

The OData approach is compatible with a RESTful architecture in that the URIs are discoverable and the HATEOAS principle is followed well. There is an initial shudder when you learn that Microsoft is behind it, but that goes away when you see that it's actually an open protocol that is used by the likes of Netflix and others.

Show me the code

In terms of a workable API, take a look at some sample code from odata4j. You'll notice that it does not expose the underling REST calls, and instead works with metadata that it can derive by exploring what has been offered by the data store. This makes the client resilient to changes, such as the addition of new types of data and the relationships between them and existing data types.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.