How to call microservice in .NET.

Question

I created a very simple REST microservice that receives email information and sends it. The microservice sending method looks something like this:

//EmailController [HttpPost] public IHttpActionResult Send(Email email) { // send email via exchange } 

Now in my application, I call it using RestSharp as follows:

 var client = new RestClient("http://localhost:51467/api/"); var request = new RestRequest("email/send", Method.POST); request.RequestFormat = DataFormat.Json; dynamic obj = new ExpandoObject(); obj.FromAddress = from; obj.ToAddress = to; obj.Subject = subject; obj.Body = body; request.AddBody(obj); client.Execute(request); 

Questions I have:

• Is this the best way to call? Obviously, later I will have to add error handling, etc., but I talk more about how I use RestSharp to call.

• I'm a little uncomfortable that my application needs to know which object the microservice expects - there is no definition / interface / contract that it uses to know for sure. Is this generally accepted as normal for REST or should I implement some kind of interface that my application has so that it can call my microservice in a slightly more specific way. Is it even possible with REST?

Thanks for any help!

Answer 1

REST services do not have a schema or WSDL function to determine the format of the service. This is what makes them lighter than traditional web services.

There is something called WADL, or the Web Application Description Language, but this is not a standard standard and is not widely supported. This is also quite controversial, as many believe that this is not necessary.

http://en.wikipedia.org/wiki/Web_Application_Description_Language

See also discussion of programmers.

https://softwareengineering.stackexchange.com/a/133693/4368

Answer 2

I would use ASP.NET Web API client libraries. It works with any REST API, regardless of whether it is encoded using .NET or some other structure.

See the details: http://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client

Nuget Package: Microsoft.AspNet.WebApi.Client

Answer 3

I usually don’t worry about additional client libraries such as RestSharp. I feel that the goal of REST is to get as close to the golden old HTTP as possible, denying the need for anything other than HttpWebRequest / Response. Working with requests / answers directly gives excellent control and encourages you to think about what is actually happening, instead of abstracting from everything, as with the traditional WCF or ASMX service.

For the microservices that I built in the past, I saved the request and response objects in separate libraries, and I distributed the source to other developers in my organization to give them support for calling the service, but this probably will not be practical for external consumers; again, I assume that the point of transition to the microservice for the full-scale WCF service is that by nature, the transmitted requests / responses are small and simple. I also felt a little uncomfortable with this practice in the beginning; however, when I started getting really responsive web applications that call microservices with javascript (usually jquery) as easy as traditional .NET, I began to see the potential for really good integration of our internal systems. Ultimately, our intranets provided actions and views in business applications that were previously not possible.

 HttpWebRequest webRequest = WebRequest.Create("http://localhost:51467/api/email/send") as HttpWebRequest; webRequest.Method = "POST"; webRequest.Credentials = CredentialCache.DefaultCredentials; //or account you wish to connect as webRequest.PreAuthenticate = true; webRequest.ContentType = "application/json"; // or xml if it your preference string jsonData = Newtonsoft.Json.JsonConvert.SerializeObject(requestObject); using (StreamWriter streamWriter = new StreamWriter(webRequest.GetRequestStream())) { streamWriter.Write(jsonData); streamWriter.Flush(); streamWriter.Close(); } HttpWebResponse webResponse = webRequest.GetResponse() as HttpWebResponse; if (webResponse.StatusCode != HttpStatusCode.Accepted) throw new ApplicationException("Unexpected Response Code. - " + webResponse.StatusCode); string response; using (System.IO.StreamReader readResponse = new System.IO.StreamReader(webResponse.GetResponseStream())) { response = readResponse.ReadToEnd(); } //swap out for regular xml serializer if you've used xml dynamic responseObject = Newtonsoft.Json.JsonConvert.DeserializeObject<dynamic>(response); 

One more tip if you work with web api, I would really suggest adding a web api and a test client to the help pages. You won’t have the automatically created wsdl that you get with WCF and ASMX, but you can get really good documentation about your microservice for other developers (even better, in my opinion, auto-generated proxy classes) and a test harness that allows you to use services from your browser

https://github.com/wuchang/WebApiTestClient https://www.nuget.org/packages/Microsoft.AspNet.WebApi.HelpPage/

Answer 4

I know this is super old, but I could not help but answered for the sake of currency.

There are two ways to transfer an API contract with other .net services, which I find particularly useful.

• Sending a nuget package with contracts (interfaces that describe the answers) and, possibly, some logic for processing your api calls
• Use swagger to describe your api (it seems they came out as the winner of the API description, Swashbuckle makes it seamless in .net), and then either manually program the bits you need in the caller, or use codegen

I often do both, swagger is also well suited for documentation and other language compatibility, and its good practice is formal about your contracts and backward compatibility.