Home/ Questions/Q 4103140
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T20:55:12+00:00

I am refactoring some SOAP and REST services. The SOAP services respond with the

  • 0

I am refactoring some SOAP and REST services. The SOAP services respond with the requested entity and nothing else. For example, a GET returns the XML representation of the entity that was requested. For errors, they throw standard exceptions. The REST services have identical behaviour.

I am modifying the REST services to throw WebApplicationExceptions and return proper http codes (e.g. http 201 for a successful post instead of always returning http 200). I am unfamiliar with SOAP, so I question what, if anything, needs to be changed.

What are the best practices for SOAP around:

1) Returning http codes (e.g. return a http 201 for POST/creation requests) for success and error cases? If so, how?

2) Throwing exceptions? Do you throw for all errors, including invalid data sent by the caller of the service? Should it be a SOAP exception or a WebApplicationException?

I am looking forward to your feedback.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    SOAP is made to be functional independent of the transport layer. Though you aren’t using it, SOAP is capable of being sent through different protocols such as SMTP. Therefore, best practices would dictate that

    1) You shouldn’t be returning HTTP codes at all in your return message. In fact, you probably aren’t able to. Success/error messages are generally going to be defined in either a custom SOAP header or the response body (response body method is simpler).

    2) Every exception thrown by the web service should be a SOAP exception. This way, the client, whatever it may be, can interpret the SOAP exception and act appropriately.

    • 0