Come chiamare un microservizio in .NET

Question

Ho creato un microservizio REST molto semplice che riceve informazioni su una e-mail e la invia. Il metodo Microservice send simile a questa:

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

Ora nella mia richiesta, ho chiamarlo usando RestSharp in questo modo:

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

Domande che ho:

1. È questo il il modo migliore per fare la chiamata? Ovviamente in seguito dovrò aggiungere la gestione degli errori ecc., Ma sto parlando più del modo in cui sto usando RestSharp per effettuare la chiamata.

2. Sto trovando un po 'scomodo che la mia app abbia bisogno di sapere quale oggetto il microservice si aspetta di ricevere - non esiste alcun tipo di definizione/interfaccia/contratto che utilizza per essere sicuro. Questo è generalmente accettato come ok per REST o devo implementare una sorta di interfaccia che la mia app ha in modo che possa chiamare il mio microservizio in un modo un po 'più definito. E 'anche possibile qualcosa con REST?

Grazie per qualsiasi aiuto!

Answer 1

I servizi REST non hanno uno schema o un tipo di funzione WSDL per definire il formato del servizio. Questo è ciò che li rende più leggeri rispetto ai tradizionali servizi web.

C'è qualcosa chiamato WADL o linguaggio di descrizione dell'applicazione Web, ma questo non è realmente uno standard e non è ampiamente supportato. È anche abbastanza controverso in quanto ce ne sono molti che ritengono che non sia necessario.

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

Vedi anche la discussione sulla programmatori

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

Answer 2

io in genere non si preoccupano con le librerie client extra come RestSharp. Ritengo che lo scopo di REST sia quello di rimanere il più vicino possibile al vecchio gold HTTP, annullando la necessità di qualcosa di diverso da HttpWebRequest/Response. Lavorare direttamente con la richiesta/risposta dà un grande controllo e incoraggia a pensare a cosa sta succedendo invece di astrarre tutto come faresti con un tradizionale servizio WCF o ASMX.

Per i microservizi che ho costruito in passato ho mantenuto gli oggetti di richiesta e risposta all'interno di librerie separate e ho distribuito la sorgente ad altri sviluppatori all'interno della mia organizzazione per dare loro un vantaggio nel chiamare il servizio ma probabilmente non sarebbe pratico per i consumatori esterni; di nuovo, immagino che il punto di partenza per un microservizio su un servizio di WCF su vasta scala sia che, per loro natura, le richieste/risposte che vengono trasmesse sono piccole e semplici. All'inizio mi sentivo un po 'a disagio con questa pratica; tuttavia, quando ho iniziato a ricevere applicazioni web molto reattive che chiamavano microservices con javascript (solitamente jquery) con la stessa facilità con le tradizionali .NET, ho iniziato a vedere il potenziale per un'integrazione davvero buona dei nostri sistemi interni. Alla fine le nostre intranet stavano fornendo azioni e visualizzazioni in applicazioni aziendali che prima non erano possibili.

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

Anche un altro suggerimento, se si sta lavorando con API Web, mi piacerebbe davvero suggerire l'aggiunta nelle pagine di aiuto API Web e client di prova.Non avrai il wsdl generato automaticamente che ottieni con WCF e ASMX ma puoi ottenere una documentazione davvero bella sul tuo microservice per altri sviluppatori (anche a mio avviso, a mio avviso, le classi proxy generate automaticamente) e un cablaggio di prova che consente di esercitare il il servizio dal browser

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

Answer 3

userei librerie client Web API di ASP.NET. Funziona con qualsiasi API REST, sia che sia codificata utilizzando .NET o qualche altro framework.

Guardate qui per i dettagli: http://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client

pacchetto Nuget: Microsoft.AspNet.WebApi.Client

Answer 4

So che questo è super vecchio, ma non potevo fare a meno di rispondere per il bene della valuta.

Esistono due modi per comunicare un contratto API con altri servizi .net che trovo particolarmente utili.

• Ship un pacchetto NuGet con i contratti (interfacce che descrive le risposte) e, eventualmente, una logica chiamata al methodise tuo chiamate API
• Usa spavalderia per descrivere il tuo api (sembra essere venuto fuori come la descrizione API vincitore, Swashbuckle lo rende senza soluzione di continuità in .net) e quindi entrambi i codici mano i bit necessari al chiamante o utilizzare un codegen

Io abbastanza spesso faccio entrambi, spavalderia è anche bello per la documentazione e la compatibilità di altre lingue, e la sua buona pratica essere formali riguardo ai tuoi contratti e alla retrocompatibilità.