问题
My team is developing an REST service wrapper over an existing SOAP based web service. We don't exactly know the SOAP service internals, just have access to the WSDL file. Our REST service wrapper will be just one-to-one mapping.
I know in real its not adhere to REST philosophy, even though please allow me to call it REST services. This REST service will be deployed on Tomcat and many client will be accessing it concurrently.
The current implementation is that for each client we will be creating an proxy object (using SOAP WSDL proxy class). This proxy object will be used to call the SOAP APIs. The SOAP requires authentication details binding over the proxy objects, so we are saving these objects for each client in memory at runtime while making first REST call to establish a session.
The saved object is fetched at runtime using an SessionID identifier. Now the problem is these proxy object occupy large memory chunks and only few REST clients are supported. (With default 64 MB only 19 REST clients can run). This is the trouble now we want to change the approach and would require your suggestions.
Kindly let me know if any better solution exists. We don't want a DB to store the objects.
回答1:
If all you can do is call a HTTP/Soap service and don't have access to the code then you create your REST services using proper REST conventions and then implement the translation to the SOAP service calls..you create the SOAP client classes automatically from the WSDL and that will save you some time.
But you WILL need to write a custom translation layer and do not make a set of hacky REST services and try to fit it into the SOAP model. try to stay true to rest and make the translation layer more complicated..it will be worth it.
来源：https://stackoverflow.com/questions/11352998/building-rest-wrapper-over-an-existing-soap-web-service