Here's my take on this.
I feel the biggest value that
SOAP and REST compliant interfaces - what we typically mean when we say "web services" - is that they are
self documenting. They don't solve any technical problems as much as they solve human
communication problems.
You could call your adhoc HTTP API a web service, and you wouldn't be wrong.
But it's not self documenting. For example, imagine a dozen new companies come to you showing an interest in your server's functionality:
- How do they know the URLs of your interface?
- How do they know what parameters your inteface takes?
- What are the valid values for those parameters?
- In what format are errors received?
- Does your interface update server state, or does it only retrieve information?
- How is the dev supposed to authenticate to your interface?
- What is the backward compatibility of the newest version of your interface?
- Can your interface participate in a transaction?
The simplest answer would be that they ask you and you tell them.
Perhaps over email or phone, or better still via good developer documentation.
But then you decide to upgrade your functionality or authentication or other aspect.
Now what? Will you call all dozen of them back and update them orally?
Or tell them the docs are updated and ask them to change their code?
There's a communication problem here, and the risk of miscommunications.
The companies behind SOAP addressed all such questions using a combination of standards.
There were standards for the WSDL language which specified the functionality, parameters, valid values and endpoints.
There were standards like WS-Security for authentication and authorization, WS-Transaction for supporting transactions, and
more.
But then they kind of overdid it. The WS-* are probably the best example for
this explosion of standards and standards body politics.
Nonetheless, they did solve a communication problem.
The alternative RESTful approach solved some of these communication problems too, but in a different and incomplete way.
It didn't come up with any new concept; it just added new meaning to existing HTTP concepts and imposed constraints on when they could be used.
So anything offered by a service was categorized into one or more
resources. The HTTP GET verb was supposed to be used only for idempotent
read ops, PUT only for creation, POST only for updation, DELETE for deletion.
What was not self documenting was the list of available resources and the meanings of parameters, but once that was provided, the operations
on them were self documenting.
REST did not offer any standards for all the other aspects like authentication or transactions. As far as REST was concerned, each aspect was just
another resource.
SOAP was complicated and often not supported by the scripting languages like PHP, javascript, and perl which were popular among web companies.
REST was simple enough to implement for web startups, who wanted to expose a public API but who didn't want to and usually didn't need to
contend with the complexities of WS-* standards. That said, REST is sometimes too restrictive and I don't think anybody is comfortable using them without developer docs.
So, as I see it, web services solve the communication problems inherent when a service grows to a point where it has a large number of diverse
external developer teams wanting to use it. If it's an interface between one client and one server and the 2 devs are buddies, web services are overkill
--------------------------
Side note:
SOAP added obvious value back in the 90s and 00s when multiple languages were being used in different companies, and clients had to integrate multiple systems from multiple vendors.
An interface definition based on text based XML transported over HTTP and following defined standards, was far better for interoperability than all the binary interfaces like Corba, RMI, DCOM
which couldn't be used by web languages like PHP and JS.
Since you are already using HTTP, I read this question as "when to use SOAP/REST compliant HTTP and not adhoc HTTP", and hence the above answer.