Consume ASP.Net REST API service

Question

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

Answer 1

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.