Do SOAP Web services support only “POST” http method

Question

I faced this question on one of interviews, so could you please tell whether SOAP Web services support only \"POST\" http method or there is some way to accept other methods

Answer 1

This is an implementation of GET in SOAP:

@WebServiceProvider(targetNamespace="http://attachment.service.soap.com/download")
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
@BindingType(value = HTTPBinding.HTTP_BINDING)
public final class ImageDownloadServiceProvider implements Provider<DataSource> {
    @Resource
    private WebServiceContext wsContext;

    @Override
    public DataSource invoke(DataSource request) {
        if (wsContext == null)
            throw new RuntimeException("dependency injection failed on wsContext");
        MessageContext msgContext = wsContext.getMessageContext();
        HttpExchange exchange = (HttpExchange) msgContext.get("com.sun.xml.internal.ws.http.exchange");
        String filename = exchange.getRequestURI().getQuery().replace("file=", "");
        switch ((String) msgContext.get(MessageContext.HTTP_REQUEST_METHOD)) {
        case "GET":
            return doGet(filename);
        default:
            throw new HTTPException(405);
        }
    }

    private DataSource doGet(String filename) {
        FileDataSource fds = new FileDataSource(filename);
        MimetypesFileTypeMap mtftm = new MimetypesFileTypeMap();
        mtftm.addMimeTypes("image/jpeg jpg");
        fds.setFileTypeMap(mtftm);
        return fds;
    }

Answer 2

I always used POST but according to the W3C standard, SOAP supports both POST and GET methods.

Edit: After some research, it seems that it's not completely true, as you can see here. It is theoretically possible to use GET because POST and GET are methods of HTTP transport protocol and SOAP can be used over HTTP.

But as you know, GET includes the request in the query string. SOAP requests (XML messages) are usually too complex and verbose to be included in the query string, so almost every implementation (for example JAX-WS) supports only POST.

Answer 3

Thread is three years old but I think that there will be still a lot of people who will give this same question to themselves and will find wrong answer in the web. The answer to the question is no, GET method can be used too.

According to SOAP specification, which can found here: https://www.w3.org/TR/2007/REC-soap12-part0-20070427/#transport both GET and POST methods can be used to exchange SOAP messages over http. The use of the HTTP POST method for conveying SOAP messages in the bodies of HTTP request uses a pattern called SOAP request-response message exchange pattern. In the case of HTTP GET a pattern is used called SOAP response message exchange pattern. The main difference of this two patterns is:

The first type of interaction allows for the use of data within the body of a HTTP POST to create or modify the state of a resource identified by the URI to which the HTTP request is destined. The second type of interaction pattern offers the ability to use a HTTP GET request to obtain a representation of a resource without altering its state in any way. In the first case, the SOAP-specific aspect of concern is that the body of the HTTP POST request is a SOAP message which has to be processed (per the SOAP processing model) as a part of the application-specific processing required to conform to the POST semantics. In the second case, the typical usage that is forseen is the case where the representation of the resource that is being requested is returned not as a HTML, or indeed a generic XML document, but as a SOAP message. That is, the HTTP content type header of the response message identifies it as being of media type "application/soap+xml"

So both GET and POST methods can be used. The other thing is that in practice mostly POST method is used.

The bad thing is that when comparing RESTful services with SOAP services, as an advantage of REST people are bringing caching, which is not available in SOAP, because SOAP uses only POST. This is totally wrong.