Как вызвать микросервис в .NET

Question

Я создал очень простой микросервис REST, который получает информацию об электронной почте и отправляет ее. Метод microservice посыла выглядит примерно так:

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

Теперь в моем приложении, я называю это с помощью RestSharp так:

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); 

Вопросы у меня есть:

1. Является ли это лучший способ сделать звонок? Очевидно, что позже мне придется добавлять обработку ошибок и т. Д., Но я говорю больше, как я использую RestSharp для вызова.

2. Мне немного неудобно, что моему приложению нужно знать, какой объект получит микросервис - нет никакого определения/интерфейса/контракта, который он использует, чтобы знать наверняка. Является ли это общепринятым как нормально для REST или я должен реализовать какой-то интерфейс, который имеет мое приложение, чтобы он мог называть мой микросервис немного более определенным образом. Это даже что-то возможно с REST?

Спасибо за помощь!

Answer 1

Услуги REST не имеют функции схемы или типа WSDL для определения формата службы. Это то, что делает их более легкими по сравнению с традиционными веб-сервисами.

Есть что-то, называемое WADL, или Язык описания веб-приложений, но это не стандарт и не поддерживается широко. Это также довольно противоречиво, поскольку многие считают, что это не нужно.

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

Также см это обсуждение Программисты

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

Answer 2

Я обычно не заморачиваться с дополнительными библиотеками клиента, как RestSharp. Я чувствую, что цель REST состоит в том, чтобы как можно ближе подойти к золотому старому HTTP, отрицая необходимость чего-либо другого, кроме HttpWebRequest/Response. Работа с запросом/ответами напрямую дает отличный контроль и побуждает вас думать о том, что происходит на самом деле, вместо того, чтобы абстрагироваться от всего, как с традиционным сервисом WCF или ASMX.

Для микросервисов, которые я построил в прошлом, я сохранил объекты запроса и ответа в отдельных библиотеках, и я распространил источник на другие разработчики в моей организации, чтобы дать им опору для вызова службы, но вероятно, это было бы непрактично для внешних потребителей; опять же я предполагаю, что точка перехода на микросервис по полномасштабному сервису WCF заключается в том, что по своей природе передаваемые запросы/ответы малы и просты. Я также почувствовал себя немного неудобно с этой практикой в ​​начале; однако, когда я начал получать действительно отзывчивые веб-приложения, вызывающие микросервисы с javascript (обычно jquery) так же легко, как и традиционные .NET, я начал видеть потенциал для действительно хорошей интеграции наших внутренних систем. В конечном итоге наши интрасети предоставляли действия и представления в бизнес-приложениях, которые ранее были невозможны.

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's 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); 

Также еще один совет, если вы работаете с Web API, я действительно предлагаю добавлять на страницах справки Web API и тестового клиента.У вас не будет автоматически созданного wsdl, который вы получите с WCF и ASMX, но вы можете получить действительно хорошую документацию о вашем микросервисе для других разработчиков (даже лучше, на мой взгляд, автогенерированные классы прокси) и тестовый жгут, позволяющий использовать услуга от вашего браузера

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

Answer 3

Я хотел бы использовать клиентские библиотеки Web API ASP.NET. Он работает с любым REST API, независимо от того, закодирован ли он с использованием .NET или какой-либо другой структуры.

Посмотрите здесь для подробностей: http://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client

NuGet пакет: Microsoft.AspNet.WebApi.Client

Answer 4

Я знаю, что это супер стар, но я не мог помочь, но ответ для валюты.

Существует два способа передачи контракта API с другими сервисами .net, которые я считаю особенно полезными.

• кораблю NuGet пакет с контрактами (интерфейсы описания ответов) и, возможно, какая-то логика вызова, чтобы methodise ваш апи называет
• Используйте чванство, чтобы описать свой API (кажется, выйти победителем описания API, Swashbuckle делает его бесшовным в .net), а затем либо вручную кодировать биты, которые вам нужны в вызывающем, либо использовать код

Я нередко занимаюсь обоими, свадьба также хороша для документации и другой языковой совместимости и ее хорошей практики формально о ваших контрактах и ​​обратной совместимости.