How to understand and start a Rest or Soap service

Question

I still can’t look at a web service and tell if it’s REST or SOAP. The question is:

1. When using one or the other
2. How to differentiate when viewing the code if it is REST or SOAP
3. Performance between one and the other

I sometimes find it difficult to formulate questions. Well, so let’s go. I arrived at the company now and saw inside a project, a web service. There is asmx.Cs and his Asp.net. This web service is within the project. It is an aspx project and I have a duty to rewrite everything using MVC 4 or 5, in my case 5. Well, then I thought about keeping the web service running, but as it is together in the same previous project and as I will have to rewrite in MVC, I will have to recreate it within my current project. I will reuse almost everything in it and maybe add something new. Hence the initial question. But I would like to know if you can take this web service and dismember the current project or this is pure utopia. Should I really rewrite? This is also my doubt.

Answer 1

A REST webservice is lighter than SOAP because the data traffic structure is generally smaller. This happens because when using SOAP the data transfer is done with XML, while a REST service usually uses JSON, which is a simpler format.

In terms of ease of use, a SOAP webservice will be easier to integrate than a REST. This is because SOAP services work on a very well defined standard, which allows the discovery of services, ie, presents metadata on the services themselves.

The standard allows to define clearly the parameters and returns of a webservice method, and is able to traffic errors... is a true RPC standard (remote Procedure call).

In addition, the SOAP standard has broad support from development tools. This way it is very easy, in any project, to use a SOAP-based webservice, because the tools allow to automatically generate the code to consume such services, creating methods and classes automatically.

A REST webservice, however, is more difficult to use, as you would have to encode and decode the messages yourself, and there is no automatic validation of the message format, and there is no way to find out which services are available, so you’ll have to know beforehand what they are.

REST is not a standard by itself... it is only a consensus on using the HTTP protocol for API messages, representatively, that is, using the verbs and HTTP status in a manner consistent with the specification. There is, for example, no requirement to use JSON.