Für alle: Leichtgewichtige Services mit ASP.NET Web API

Die aktuellen Entwicklungen vor allem rund um mobile Anwendungen und Cloud Computing bedeuten für viele Softwareprojekte ein Umdenken in der Architektur. Wer das heute ignoriert, könnte sich morgen in Kalamitäten befinden. Christian Weyer zeigt Ihnen, wie Sie die Idee von leichtgewichtigen Web-/HTTP-APIs mit ASP.NET Web API umsetzen können. In gewohnt praxisorientierter Manier werden Sie durch die Konzepte und wichtigen Funktionalitäten des Frameworks geführt, um interoperable servicebasierte Architekturen für .NET-, Web- oder mobile Anwendungen aufziehen zu können.

Transcript

1. Christian Weyer | thinktecture Für alle: Leichtgewichtige Services mit ASP.NET Web API think mobile!
2. Christian Weyer • Solution architect and principal consultant at thinktecture • Focus on – distributed applications, service orientation – cloud computing – interoperability, cross-device – pragmatic end-to-end solutions – Windows Server, ASP.NET, Web API, SignalR, WCF, Windows Azure • Microsoft MVP for Windows Azure (Architecture) • ASP.NET Web API Advisory Board Member / ASPInsider • http://blogs.thinktecture.com/cweyer • christian.weyer@thinktecture.com • @christianweyer think mobile! 2
3. Objectives • Lightweight web-based architectures • Web APIs for service-based applications • HTTP as an application protocol • ASP.NET Web API as a Web API framework • Client/consumer applications 3
4. Enterprise? ISV? Web? … any difference …? 4
5. The world is changing... 5
6. From Web Sites to Web APIs 6
7. From PCs to Devices 7
8. From On-premises to the Cloud 8
9. Modern Business Applications: Reach! 9
10. Ubiquitous access – client platforms • .NET clients • Silverlight clients • Pure HTML(5) • JavaScript & jQuery • Android (Java) • iOS (Objective-C) • Embedded (C/C++) • Java • Any client, any device, actually 10
12. Architectural approaches to Service Orientation • „SOAP“ / WS-* – transport protocol independent – „secure, reliable and transacted“ (WS-*) – sophisticated and complex protocol stack – interoperability may become difficult – „the best RPC so far“ – „on the web, not of the web“ • Web/HTTP („REST“, anyone?) – fully embrace HTTP – least common denominator technologies – less functionality (KISS?) – reach and interoperability said to be better – „easier to use“ 12
13. Which one is ‚better‘? 13
14. Which one is more ‚polite‘? 14
16. Distributed application architectures for modern applications • Reach vs. rich • Base foundation vs. features • Light-weight vs. heavy-weight 16
18. HTTP – the application protocol • Application protocol • URIs • Verbs • Headers • Content types • Content negotiation • Status codes 18
19. Web API framework requirements • Need a first class HTTP programming model • Easily map resources to URIs and implement the uniform interface • Rich support for formats and HTTP content negotiation • Separate out cross cutting concerns • Lightweight, Internet scale • Realize REST-ful or RPC-ish architectures – Being pragmatic, not idealistic 19
20. ASP.NET Platform 20
21. ASP.NET Web API: Implementing a Web API • Derive from ApiController • Implement your actions – Actions map to HTTP methods – Prefix method name with desired HTTP method – e.g. PostComment – Use [HttpGet/Post/Put/Delete] if you prefer a different name – Supports async with Task<T> – Actions expose explicit DTO data, HttpResponseMessage or JsonValue / dynamic 21
22. Routing • Maps a URL space to your Web API controllers – {controller} + “Controller” • Can be tailored using default values and route constraints • V2 offers attribute-based routing [HttpGet("customers/{customerId}/orders")] public IEnumerable<Order> GetOrdersByCustomer(int customerId) { ... } 22
23. Working with HTTP • “First class experience” for using HTTP – exposing HTTP as an application protocol in its full glory and not hiding it • Use of HttpRequestMessage and HttpResponseMessage – a way of giving direct access to the HTTP protocol, without some of the parsing and encoding complexity – not obtained from the “current context" (e.g. WebOperationContext.Current in WCF) 23
24. Model binding & formatters • Model binding can “shred” the request and bind it to individual parameters • Values are taken from the URL (route variables, query parameters) or from the body • MediaTypeFormatters are used to deserialize the request body based on the content type – XML, JSON, form-url-encoded supported out of the box • Request data is validated as it is bound to the parameters 24
25. Content negotiation • Response format is determined based on HTTP content negotiation • Request Accept header expresses desired format(s) • Server selects a format for the response based on the request and the available MediaTypeFormatters • Help/documentation page available at /help 25
26. Query composition • Supports OData URL query syntax • Queries enabled by simply returning IQueryable<T> from a method • Orthogonal to format and content negotiation 26
27. Hosting & Clients • Two hosting options – ASP.NET Web Application (IIS) – Self-host server option (console application, Windows service, etc.) • HttpConfiguration is the common denominator • In v2: OWIN as base for hosting Web API, SignalR etc. • HttpClient is a cross-.NET HTTP client API • Use plain XmlHttpRequest, or jQuery’s $.ajax, or $http in AngularJS) 27
28. Summary • Web APIs as a lightweight approach to distributed application architecture – Reach (vs. richness) – Limited feature set – HTTP as an application protocol • ASP.NET Web API makes it easy to build HTTP services that can reach a broad set of clients • ASP.NET Web API as a base for creating REST-ful and/or RPC-ish services – IIS hosted & self-hosted • HttpClient as one possible Web API client programming API for .NET applications 28
29. Resources • christian.weyer@thinktecture.com • http://www.thinktecture.com • thinktecture’s GitHub Repositories – https://github.com/thinktecture • Christian Weyer’s GitHub Repositories – https://github.com/ChristianWeyer • ASP.NET Web API – http://www.asp.net/web-api • WebApiContrib – https://github.com/WebApiContrib 29
30. By the way… 30
31. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven 31