C# – the difference between SOAP and REST webservices? Can SOAP be RESTful

crestsoapwcfweb services

From MSDN magazine https://msdn.microsoft.com/en-us/magazine/dd315413.aspx and https://msdn.microsoft.com/en-us/magazine/dd942839.aspx
I understand that

When RESTful endpoints are asked for data using HTTP, the HTTP verb used is GET.

Using REST means that you can take advantage of HTTP caching and other features, like Conditional GET, that aid in scaling services. Many of these techniques can't be used with SOAP because SOAP uses POST only over HTTP.

From the Wikipedia page http://en.wikipedia.org/wiki/Representational_state_transfer

RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.[

But will it be a violation of REST architecture to use HTTP POST to get data from a resource?
In other words, can a SOAP based webservice be RESTful?

Are there any other differences between RESTful and SOAP based webservice?

Best Answer

Introduction

I'm posting this as an answer because comments just don't suffice. Here is what I want to summarize for you.

First, we'll start with these two references:

http://spf13.com/post/soap-vs-rest

http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/

Lastly, I want to start this post off by saying the following:

SOAP and REST were both designed to solve the following problem: how do two disparate applications, programmes or devices interchange and share data between each other, in an extensible and easily-understood manner?

RESTful Services

By design RESTful (Representational State Transfer) services use HTTP and the HTTP verbs (GET, POST, PUT, DELETE) to indicate intent. These verbs very clearly indicate to the user what is going to happen when they are used. The server can use them to make preemptive decisions. That is, it can make a decision long before the action is ready to take place.

Consider this, you have to access a small bit of data from a users Insert Service account. Which is easier, a GET endpoint/users/account/id request, or a POST endpoint/users/account request that has a body of id? By definition of REST, the POST request violates the basic agreement that REST implies. That is: the server is expected to know, before the data has arrived, what intentions with it the user has. This is the basic fundamental that REST attempts to guarantee.

This fact, no, this fundamental, mandates that RESTful communication be permitted to indicate what intention the client has before the client begins to send data. This allows the server to accept and reject messages long before they arrive, thus reducing processing load.

Another aspect of REST (especially with the Twitter, Facebook and Google APIs): RESTful services, with the focus and mandate on HTTP, can take advantage of HTTP response headers. That is, they may respond with an HTTP 403 Forbidden message if the client is not permitted access. SOAP-based services may not. The resulting message must indicate such a result.

RESTful services tend to associate HTTP verbs (or actions) with nouns (or entities/objects.) Generally speaking, plurality and singularity imply more about the action. I.e. GET RootEndpoint/Employees would be expected to return all employees (or at least a large group matching a specific criteria.) Whereas GET RootEndpoint/Employee/12 would be expected to return only one employee. (Generally, Employee with ID 12.)

RESTful services make a direct correlation between the HTTP verb (GET, POST, PUT, DELETE) and the action. This is the purpose of the tie between the two: there is nothing special that needs added to the message body to indicate what the user intends to do. (I'll continue to stress this point throughout.)

REST was designed entirely for HTTP. And it is very good at it's job.

RESTful Filtering

Generally speaking, to filter REST service requests you would include multiple URL segments with each segment indicating what parameter follows it.

I'll take an example from the Spotify API: https://developer.spotify.com/web-api/get-playlist/:

Get a Playlist

Get a playlist owned by a Spotify user.

Endpoint

GET https://api.spotify.com/v1/users/{user_id}/playlists/{playlist_id}

Request Parameters

+---------------------------------------------------+
| Path parameter | Value                            |
+---------------------------------------------------+
| user_id        | The user's Spotify user ID.      |
| playlist_id    | The Spotify ID for the playlist. |
+---------------------------------------------------+

In that API endpoint, you specify that you are looking for a users object with user_id of {user_id}, and a playlists object (within that users object) with the playlist_id of {playlist_id}.

Some RESTful services allow combination flags on parameters.

Take the Stack Exchange API, for example. You can fetch multiple questions or answers by separating them with semicolons, and it will essentially filter to just those questions or answers.

If we analyze this endpoint (/questions/{ids}/answers), you'll see that it specifies:

Gets the answers to a set of questions identified in id.

This method is most useful if you have a set of interesting questions, and you wish to obtain all of their answers at once or if you are polling for new or updates answers (in conjunction with sort=activity).

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects.

The sorts accepted by this method operate on the follow fields of the answer object:

This is also a good example of an API that allows additional GET requests to filter/sort the results even further.

Example of usage: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow

Now, if we do the same with the /answers/{ids} endpoint, we can come up with something along the lines of: https://api.stackexchange.com/2.2/answers/30582379;30581997;30581789;30581628?order=desc&sort=activity&site=stackoverflow. This pulls the four specified answers for us.

We can combine even more, for example, with the SE API and include filters to restrict the fields returned: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow&filter=!)V)P2Uyugvm. (See this link to /2.2/filters for an explanation of that filter parameter.)

SOAP-based Services

Enter SOAP (Simple Object Access Protocol), which was the predecessor to REST. SOAP solved this problem by sending messages back and forth. They use XML (though you could build a SOAP-based service without it, similarly to being able to build a RESTful service without JSON) to exchange a message, whereby the server has no initial indication of what to do.

SOAP-based services solve this issue in a manner that is agnostic of transport medium. The server and client need not use HTTP, or even TCP at all. They just need to use the same, or compatible transport mediums. In fact, you could think of the modern-day corporate environment as a SOAP-based service. When you need to get new supplies, you put in a requisition to your office manager, who then responds with a message. Upon receiving the initial requisition, your manager has no idea if it is permitted or not. They have to read the rest of the requisition in order to determine whether it is a valid request or if it is invalid.

SOAP was designed around RPCs (Remote-Procedure Calls), many firewalls block these. So, as a result, SOAP was modified to work over HTTP. It was designed to integrate vastly different technologies.

Because SOAP is designed around messages, it is a much more verbose service. It is generally easier to represent compound actions in SOAP services. That is to say, if you are requesting objects based on many criteria (instead of just one) SOAP tends to have better interface for this.

SOAP-based Filtering

SOAP-based services filter with additional fields in the RPC. How these fields are combined is up to the provider.

I'll take an example from the Global Weather API: http://www.webservicex.net/globalweather.asmx?op=GetWeather:

GetWeather

Get weather report for all major cities around the world.

Test

To test the operation using the HTTP POST protocol, click the 'Invoke' button.
+---------------------------------------------------+
| Parameter      | Value                            |
+---------------------------------------------------+
| CityName:      |                                  |
| CountryName:   |                                  |
+---------------------------------------------------+

If you specify, for example, "Blanding" and "United States" you will see the generated XML looks like the following:

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <GetWeather xmlns="http://www.webserviceX.NET">
      <CityName>Blanding</CityName>
      <CountryName>United States</CountryName>
    </GetWeather>
  </soap12:Body>
</soap12:Envelope>

This would be submitted (for an HTTP SOAP request) as a POST-based call to http://www.webservicex.net/globalweather.asmx/GetWeather.

Back to the original question:

Can a SOAP-based webservice be RESTful?

This was your original question, and I believe it stands to reason that it cannot, based on the information I have provided. These two services are mutually-exclusive. REST intends to solve the issue with the exchange of headers that indicate intent, and message bodies that indicate purpose. SOAP intends to solve the issue with the exchange of messages that indicate intent and purpose.

Will it be a violation of REST architecture to use HTTP POST to get data from a resource? Yes. The RESTful service architecture is designed to use the term POST to represent a specific action. Each HTTP verb in REST represents what that action intends to do.

As I said in the comments on the initial question:

You can use HTTP POST to get the data, but it's not a RESTful service then, as the HTTP verb has no meaning. RESTful services are RESTful because the verb indicates the action.

What do I choose, SOAP or REST?

This part exists primarily for future readers.

Both protocols have advantages and disadvantages, and you should choose which protocol you are using based on the requirements of the problem. Instructing you on how to accomplish that is beyond the scope of this question and answer. That said, there are three things to consider: know your project, know your requirements, and most of all, correctly document it for your audience.

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

C# – the difference between const and readonly in C#

Apart from the apparent difference of

having to declare the value at the time of a definition for a const VS readonly values can be computed dynamically but need to be assigned before the constructor exits.. after that it is frozen.
const's are implicitly static. You use a ClassName.ConstantName notation to access them.

There is a subtle difference. Consider a class defined in AssemblyA.

public class Const_V_Readonly
{
  public const int I_CONST_VALUE = 2;
  public readonly int I_RO_VALUE;
  public Const_V_Readonly()
  {
     I_RO_VALUE = 3;
  }
}

AssemblyB references AssemblyA and uses these values in code. When this is compiled:

in the case of the const value, it is like a find-replace. The value 2 is 'baked into' the AssemblyB's IL. This means that if tomorrow I update I_CONST_VALUE to 20, AssemblyB would still have 2 till I recompile it.
in the case of the readonly value, it is like a ref to a memory location. The value is not baked into AssemblyB's IL. This means that if the memory location is updated, AssemblyB gets the new value without recompilation. So if I_RO_VALUE is updated to 30, you only need to build AssemblyA and all clients do not need to be recompiled.

So if you are confident that the value of the constant won't change, use a const.

public const int CM_IN_A_METER = 100;

But if you have a constant that may change (e.g. w.r.t. precision).. or when in doubt, use a readonly.

public readonly float PI = 3.14;

Update: Aku needs to get a mention because he pointed this out first. Also I need to plug where I learned this: Effective C# - Bill Wagner