Light-weight architectures for ‚everyone‘ with ASP.NET Web APIs – beyond the Web

Service orientation, SOAP and maybe WCF are now part of the tool box for distributed applications. But nowadays some rethinking is required. The triumphant advance of mobile devices and an increased drive towards open architectures may not quite fit the ‘traditional’ implementation of service-orientation. In this talk, Christian Weyer shows how to architecturally meet those new requirements and introduces you to the world of lightweight web APIs. Based on the new ASP.NET Web API stack, you will see how to implement web APIs and consume them in various client applications.

Transcript

1. DevWeek 2013 Light-weight architectures for ‚everyone‘ with ASP.NET Web API – beyond the Web Christian Weyer christian.weyer@thinktecture.com think mobile!
2. 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 • http://blogs.thinktecture.com/cweyer • christian.weyer@thinktecture.com • @christianweyer think mobile!
3. 3 Objectives • Light-weight 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
4. 4 The world is changing...
5. 5 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
6. 6 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“
7. 7 Enterprise? Web? … any difference …?
8. 8 Distributed application architectures • Reach vs. rich • Base foundation vs. features • Light-weight vs. heavy-weight
10. 10 HTTP recap (illustrated) • Application protocol • URIs • Verbs • Headers • Content types • Content negotiation • Status codes
11. 11 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 • Light weight, internet scale • Realize REST-ful or RPC-ish architectures – Being pragmatic, not idealistic
12. 12 ASP.NET Platform
13. 13 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
14. 14 Routing • Maps a URL space to your Web API controllers – {controller} + “Controller” • Can be tailored using default values and route constraints
15. 15 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)
16. 16 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
17. 17 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 (by default)
18. 18 Testability and IoC • Removed reliance on static context objects • For easy unit testing, dependencies (or relevant fakes) can be supplied via simple constructor parameters • At runtime, those constructor parameters can be supplied via the DependencyResolver • DependencyResolver is where to connect your favorite IoC container – Found on HttpConfiguration instance • More robust: implement IHttpControllerFactory to hook up IoC container • Directly pass HttpServer into HttpClient
19. 19 Query composition • Supports OData URL query syntax • Queries enabled by simply returning IQueryable<T> from a method • Orthogonal to format and content negotiation
20. 20 Filters • Filters are used to handle cross cutting concerns • Filters can be configured globally, per controller, or per action as an attribute • Filter types: – Action filters run after model binding has occurred – Authorization filters run before model binding and are specifically for authorizing the user – Exception filters handle generating responses for error cases in a centralized way
21. 21 HTTP request/response handling • Message handlers: Task<HttpResponseMessage> SendAsync( HttpRequestMessage request, CancellationToken cancellationToken)
22. 22 Hosting & Clients • Two hosting options – ASP.NET Web Application (IIS) – Self-host server option (console application, Windows service, etc.) • HttpConfiguration is the common denominator • Web APIs should be consumable from anywhere • HttpClient is a cross-.NET HTTP client API • Use plain XmlHttpRequest, or jQuery, or any other JSON/REST API in JavaScript
23. 23 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
24. 24 Resources • http://blogs.thinktecture.com/cweyer • christian.weyer@thinktecture.com • ASP.NET Web API – http://www.asp.net/web-api • WebApiContrib – https://github.com/WebApiContrib • My samples – https://github.com/ChristianWeyer • thinktecture Open Source projects – http://thinktecture.github.com/
25. 25 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven