For the sake of personal use and for the educational reasons I wanna make a Java wrapper around a certain service's web API. That is, no additional software is required to use it on a client machine - just my code.

I also want to make that wrapper reusable and possibly utilized by other people who might want to access that service from Java code.

So my question is: is there any common practice or a standard design pattern for the cases like mine that states that such wrappers be packed in a Java Bean and used accordingly? Or is such software typically distributed in a source code form and compiled as a part of the project that makes use of it?

  • 1
    Possible duplicate of When should I design a class library using java bean standards? – gnat Feb 8 '17 at 19:36
  • @gnat now that I've read the question you posted a link to, I still have no idea how to apply that info for my case. Especially since there's only one answer there, and the phrases like "If you have an object that performs actions and directs traffic, that is not a candidate for a Java bean" don't make any sense to me. So I'd rather ask for my question to be treated separately. – Semisonic Feb 8 '17 at 19:45
  • You can find many many Java wrappers for Web APIs online. e.g. for GitHub, IMDB, Facebook, whatever. I'd take a look at them to get ideas as to a good approach. Personally, I think JavaBeans were a terrible evil idea cause they tend towards anemic domain models, but in some cases they are o.k.-ish. – user949300 Feb 8 '17 at 21:13

IMHO providing wrappers around 3rd party services/dependencies can be advantageous in some cases.

One of these case is where the 3rd party service is used extensively or in multiple modules, therefore it may incur a high cost to perform upgrade to the service across multiple modules, thus avoiding dependency lock-in.

Another case can be where multiple 3rd party services provide similar primary features, but competitive secondary features, and there might be a chance where the provider of the service can be changed during the lifetime of the project.

Your wrapper can expose functionalities that are valuable to your project, and add more when needed, instead of exposing all the features from the 3rd party API at once. It is easier to evolve when you are exposing lesser functionalities.

"When in doubt, leave it out" - Joshua Bloch

In my (sort of similar) case, I exposed storage functionality in my internal library for multiple projects to store some internal data structures, however the dependency on the storage API is hidden in wrapper functions. This allow me to change the provider of storage API easily.

  • 1
    per my reading this doesn't even attempt to address the question asked, should it be packaged as a Bean. See How to Answer – gnat Feb 9 '17 at 7:29

Your Answer

