CODEWITHSUNDEEP
.netwcfarchitectureasp.net-web-api
Walkingsteak
Walkingsteak

Reputation: 349

Expose an API that network clients can call

Context: I have several embedded devices connected to a computer with RS232. On this computer I am gonna create a program which can control these devices, sending commands to individual devices to change their configuration or to retrieve logged data for a given timespan, among other things.

I want all the functionality in this program to also be available to other computers on the network. For a "proof of concept" I made a simple WCF service with functions such as

void SetTime(string comPort, DateTime time)
DateTime GetTime(string comPort)
List<string> GetSensors(string comPort)
List<LoggedValue> GetLoggedData(string comPort, string sensorName, DateTime start, DateTime stop)
void RestartDevice(string comPort)

What I liked with WCF was that you could automatically create the proxy classes for the service in Visual Studio, and could work directly with the custom classes defined in the service, such as LoggedValue.

However, I see many claims about WCF being too complex and has a high overhead, and that asp.net web API (or mvc web API 2 or whatever it is called) is the way to go to create an API which is simple to call (simple HTTP requests) and low overhead. While I can agree with those two points, I feel you lose a lot of the advantages with the strongly typed classes in WCF.

Also, I find that the "CRUD"-operations doesn't always translate too well to all the things I want to do; I will never be doing any Create or Delete operations, and the only Update will be change of configuration values, such as setting the logging interval. Calling functions in the API that won't return a value, such as void RestartDevice(string comPort) also seems unnatural with web api (how would you do this?)

Since I don't have too much experience with either technology, which direction seems the most natural to use? This is not a service that will be accessed by many clients, and the rate of requests will be very low.

Upvotes: 1

Views: 78

Answers (2)

tom redfern
tom redfern

Reputation: 31750

I would agree that WebAPI is slightly simpler to implement. I've been using WCF for nearly 10 years and WebAPI for about 3 years and I find myself rarely using WCF these days. Consuming WebAPI is also very straightforward using HttpClient.

I don't believe you need to worry yourself overtly over which technology stack you ultimately go for. Both technologies support your requirement for RPC, or command-style operations, both are well supported, easy to consume, and have roughly the same management overhead.

I would agree with your analysis that your device operations contract is not easily expressible as a set of RESTful operations, so if you choose WebAPI just ignore all the conventions around the verbage (GET, PUT, etc), and just use POST for all your commands.

Upvotes: 1

kindasimple
kindasimple

Reputation: 2427

If you are doing proof of concepts, you might as well try one with NetMQ. Its a .NET port of ZermMQ, and to make it convenient there is a nuget package available.

Sure, WCF is a good flexible solution. Depending on your communication strategy you might find that a pub/sub or broadcast model allows you to do something you cant do with a web API.

Upvotes: 0

Related Questions