Design to reduce code redundancy - Java/WebServices

Question

Hi All, 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?

Answer 1

You are right, If only the request/response XML differs in layout only and the data is same then you can make XSLTs for both of them which will convert it into proper XML as per your POJO.

Then you can use Castor mapping for XML to POJO object right? And you will get your needed object. But you have to make the object common for the code right?

What i mean is, use common object for your logic and use some another logic to get that object from your Request/Response objects for SOAP/REST. Because the data you are sending will be same in both kind of methods, you just need to handle Object to object conversion. That can be done directly OR using Object to XML and XML to object.depends which you prefer.

hope this helps.

Parth.

Answer 2

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.