Scenario:
I’m working on a web services project. It supports SOAP and REST. The SOAP request and response are handled by XmlObjects. The REST architectures uses plain POJO’s for request and Response. I have a common controller to handle the request from SOAP and REST. This controller understands a common object (Request Object). And , the controller sends back a Transfer Object. In front of the controller , I have a request translator to translate the SOAP/POJO objects to common Request Object. And also a response translator to convert the transfer objects to SOAP/REST view objects.
Problem:
I have 2 request and response translators. The SOAP/REST request and response translators look the same. But, they take a different object as input. So it looks like I have the same code 2 times.
How to avoid this redundancy?
Solutions that I thought of : Bean mapping.
Is there anything else more elegant than this?
I assume both your “REST” and “SOAP” APIs must do the same thing and are therefore quite parallel. You ought to (re)read Roy Fielding’s description of the REST architectural approach and then decide if these APIs are truly RESTful in Roy’s very precise definition of the term. If they are both RESTful, then just ditch your SOAP APIs: SOAP is harder to use, doesn’t leverage HTTP caches, and adds nothing over your REST APIs.
If they are both non-RESTful (ie, they have a Remote Procedure Call flavor and the “REST” APIs just happen to do RPC operations using HTTP and XML), then assuming you can’t convert them to the REST architectural style, you can at least factor out the POJO<==>XML mappings using a library like XStream.