Thank you for the explanation. This will help me to sound like I know what I am talking about :) when we have the first conference to discuss this.

>The thing is that Web Service is a broad term these days. It used to mean SOAP services (ie. WCF in .NET). However, today most modern Web services are based on REST which is just HTTP with the consumption of the data left up to you. REST services are easier to call because you don't need a dedicated SOAP client but just an HTTP client. However, you're left on your own to parse the data that comes back. Typically for REST that's JSON and you can deserialize JSON easily enough in .NET and most other platforms, but in .NET at least you have to have objects that match the structure of the data you're capturing to begin with. SOAP used to take care of that for you by creating the proxy classes based on the service definition. With REST you have to create those types yourself (or dynamically parse).
>
>That's why I say you need to know what the client is and how they expect to use the data. If it's a big corporate client or a government agency that's consuming the data they're probably more comfortable with SOAP. If it's broad reach service especially one that will be consumed from devices and clients directly, then REST is a better choice.
>
>+++ Rick ---
>
>>First, thank you for your input (although most is way over my head, unfortunately). And I don't know if this is a .NET to .NET. The situation is as follows. A company approached my customer and they want to implement their application. But my customer insists that the records of this (3P) application have to be duplicated (or entered) into my application SQL Server. So I have to (it is up to me) suggest/direct how their data can go into my application database. This is why I thought of Web Services. But this other company, when creating a Web Service (my understanding is that they have to) may not use .NET but some other technology.
>>
>>>If this is an internal service and you are calling from .NET to .NET then using a SOAP based Web Service may very well be the easiest solution. If it's a public facing solution it's probably better - as Craig has mentioned - to use a REST based API using ASP.NET Web API. While REST based services are more appropriate today, consuming them can be a bit more work as there's no service definition and you manually need to create the types that can receive the client data. With SOAP you can just point at the service and get a proxy generated for you - so it can be somewhat easier to work with.
>>>
>>>If you go the REST route you can use Web API on the server, and a standard HTTP client (like HttpClient()) that can automatically deserialize JSON into objects that you create on your own.
>>>
>>>+++ Rick ---
>>>
>>>>Hi,
>>>>
>>>>I need to understand (and learn) a .NET technology that would be used as follows:
>>>>
>>>>Some 3P software has to add record(s) to a table in SQL Server database. Then my application will "deal" with this record(s) (this is not relevant to the question). I may need to "tell" the 3P software how the data from their program will go to the database. Will I need to build Web Services to consume their data/messages? (not sure if "consume" is the right term though). Or another technology?
>>>>
>>>>What technology should I look at and learn?
>>>>
>>>>TIA