I am building a REST API to expose most of functionality of an existing Java API. Both APIs are for internal use within my organization; I do not have to design for external use. I have influence over both APIs but am implementing the REST one. The Java API will continue to be used for local applications (it's not being "retired"), but the REST API will be used for significant new development.
Some of the Java API classes are simply data (beans with properties, getters, setters). And at least some of these make sense to transmit (in some form) over the REST API as data (which will be marshalled to XML or JSON). For example, a class that stores info about a server machine. I am faced with the following choice for these data classes: Do I...
- expose the original Java class (or a subclass) directly in the REST API, or
- make a new data transfer class (DTO pattern) specifically for the REST API?
Either way I'll have REST data transfer classes; the question is whether to annotate the originals or create new ones (which may be near copies of the originals). There may be other choices, but I'll focus mainly on those two.
Arguments for #1:
- DRY (don't repeat yourself)
- Faster to implement
- Easier to upgrade REST API
Arguments for #2:
- What if REST API needs to be versioned separately from Java API? (This is somewhat likely.)
- What if there are significant changes to the Java data classes such as removal of properties, adding of behavior, or changes to class hierarchy? (This is also somewhat likely.)
Bottom line is that it seems like a tradeoff between DRY (#1) and decoupling (#2).
I'm leaning toward starting with #1 and then if problems arise moving to #2 later, following the agile guideline of not building what you can't prove you need. Is this a bad idea; should I start with #2 if I think I may end up there anyway?
Are there major arguments/consequences missing from my lists?