We've build an application using Spring and deployed it with Tomcat. We have a working REST interface, however one of our clients only has a SOAP client.
My understanding is that a SOAP web service and a REST web service cannot coexist on the same port or application.
What are my options for accepting a SOAP request with as little development as possible. Should I accept a soap packet via the rest interface and parse the XML? Or can I setup a SOAP interface communicate with my REST interface and respond back?
I'm using Gradle as my build tool. It would be nice to have the solution as part of a single WAR file
In my experience, you can mix SOAP and REST in the same application if you're very careful about XML namespaces for JAXB. However, I wouldn't recommend it since updating one means risking the other's stability. Here is what I recommend...
- Setup a multi-project build in gradle
- Create three projects, one for the business logic, one for the REST interface, and one for the SOAP interface
- Modify the REST/SOAP interface to use common business logic project
- Deploy as two separate WARs
Should I accept a soap packet via the rest interface and parse the XML?
SOAP is a protocol and not just a format so this probably won't work with most (any?) frameworks.
Or can I setup a SOAP interface communicate with my REST interface and respond back?
You probably could at the expense of performance and/or maintainability.
We have a project that has similar requirements. We still have to support SOAP and we're going forward with ReST.
There is no reason that the two will conflict. Since you're using spring, you can even have the same domain objects as a response that gets marshalled to XML and JSON as your preference.
What you have to do is create different URI for the two. e.g someService/**
for the SOAP and some-rest
for the ReST implementations. You can have a service layer to handle shared logic (mostly the code needed on the end point and the rest controller is to fetch the required data from the service layer and sending it to be marshalled)
Just add some entry to your web.xml
file to indicate the rest path and the endpoint paths...
It sounds like your web service is primarily REST (it's 2013) but you have to support soap for a limited case. I'd design your web service with rest primarily in mind, but perhaps use a separate mechanism to indicate to the server that the client requires soap support. If possible, have the soap client send an http request header or use modified URL that perhaps ends in .soap. In any case there's no reason why you can't support both protocols on the same app.
You can do that by making annotation of both rest and soap on class implementation, and also creating interface to hold the method annotation for soup. and in class implementation put rest annotation on method and configure the web.xml
file to add servlet
for rest implementation you use.
_ Add configuration for your Rest implementation you use
[ ApplicationConfiguration is class only extend Application ]
<servlet>
<servlet-name>com.fawryis.ebpp.core.rs.config.ApplicationConfiguration</servlet-name>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>com.fawryis.ebpp.core.rs.config.ApplicationConfiguration</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
@javax.jws.WebService(endpointInterface = "com.test.ebpp.autopayment.tess.ejb.GService", targetNamespace = "http://ejb.test.autopayment.ebpp.tess.com/", serviceName = "testPaymentService", portName = "testPaymentPort")
@Path(value = "/testPaymentService")
public class testPaymentPortBindingImpl implements
testPaymentService {
@Override
@POST
@Consumes({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
public Typeobj process(Typeobj request) {
//type your code
}