1

I am creating ASP.Net REST API application and stuck on the part where I should consume the REST service.

I am not sure how to find the way let me accomplish the following:

1. I don't want it to be Pure REST in another meaning I don't want to lose the ability to use Sessions and authentication.

2. I want to have Simple and efficient Consuming for API without redundancy

In way help me to get proxy classes in Client without forcing problem in having duplicate Model in client Side.

What I reach So far (And correct me if I wrong)

1. I Can use WCF which Achieves me the second approach Using DataContract but it doesn't look the same for the first approach which will require me to create the Session with my own.

2. Or Going with Web API 2 to get leverage from having session built in, There is a way to Achieves me the second approach Using OData wich would help me in generating proxy classes.

Did someone had the same issue? Can you give any pros/cons of each system? And what is the best Simple and Elegant way to go with?


To be more precisely

Currently, I have a .NET platform that I need to expose to different clients

(ASP.NET MVC, iOS and Android), I will be developing these clients myself not a third party.

In the meantime, those Clients have their own business layer which executes some logic and persists data using entity framework ODTC into an ORACLE DB,

what I am thinking now and what I need is to have the ASP.NET Web API 2 or WCF To serve those clients by migration the business layer and unified it into API

which one should I use ?

what is the best efficient approach to accomplish the past two scenarios ?

Thanks in advance

  • You seem to have put a lot of effort into this question, but I do have a simple answer for you: I would reach for anything but WCF probably 95 percent of the time. Web API 2 is certainly a viable, sensible, and much simpler and more straightforward alternative. – Robert Harvey Jul 7 '16 at 19:56
2

WCF uses SOAP, which has a lot of overhead to use. In this case, you would probably need to auto generate clients for particular platforms, because it would be too much work by hand. There are a lot of features in WCF, but it has generally fallen out of favor due to the communication overhead and code required compared to simpler models like ordinary HTTP requests.

Using Web API 2 or even just MVC (for limited same-origin scenarios) for routing and controller capabilities would be the superior choice for ease of use by clients. Any client that can make an HTTP request could use your API without a generated proxy. Web API still allows you to plug in things like sessions. There are copious examples on the web on how to make an HTTP GET/POST/etc. request from just about any given client platform, including the command line (via curl).

As far as clients and servers agreeing on contracts, I have an answer on that here. Basically, creating data classes for requests on both ends is expected and normal, depending on your scenario. Data contracts can be specified in other ways without direct library sharing. You could still share a library between client/server if you don't mind tightly coupling your client and server to the same platform and to each other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.