Downloaded 43 times
![Dispatching actions
●
By default HTTP verb based (RESTful)
●
Actions matched:
●
by prefix (i.e. GetAll, GetById) or
●
by action attribute (i.e. [HttpPost])
●
Can be changed to action based (RPC style)
@filip_woj](https://image.slidesharecdn.com/presentation3-130118231902-phpapp02/85/Embrace-HTTP-with-ASP-NET-Web-API-42-320.jpg)
![Dispatching actions
●
By default HTTP verb based (RESTful)
●
Actions matched:
●
by prefix (i.e. GetAll, GetById) or
●
by action attribute (i.e. [HttpPost])
●
Can be changed to action based (RPC style)
@filip_woj](https://image.slidesharecdn.com/presentation3-130118231902-phpapp02/75/Embrace-HTTP-with-ASP-NET-Web-API-42-2048.jpg)
Embrace HTTP with ASP.NET Web API
- 1. Embrace HTTP with ASP.NETWeb API @filip_woj
- 2.
- 3. What is ASP.NETWeb API? ● New Microsoft framework (RTM August 2012) for building HTTP services & applications ● Aimed at simplyfing and standardizing HTTP area on the MS stack (see: WCF / ASMX / MVC / HttpHandlers) ● Supports both REST and RPC style services ● Open source! @filip_woj
- 4. But it's Microsoft! From:Scott Hanselman's “ONE ASP.NET” talk at aspconf 2012 @filip_woj
- 5. Web API origins ● HTTP in WCF ● WCF REST starter kit ● WCF Web API ● finally adopted some concepts from ASP.NET MVC @filip_woj
- 6.
- 7. A mix ofWCF Web API & MVC ● from WCF Web API: - content negotiation - message handlers - REST & dispatching based on HTTP verbs – code based configuration @filip_woj
- 8. A mix ofWCF & MVC ● from MVC: - model binding concept - controller based approach & RPC - routing - filters @filip_woj
- 9.
- 10. “ASP.NET” “Web API” ● The name creates lots of misconceptions ● “ASP.NET”: it doesn't require neither ASP.NET, nor IIS to run ● “Web API”: it's an HTTP framework, that can do much more than "just" API @filip_woj
- 11. How can itwork without ASP.NET/IIS? ● Web hosting: ASP.NET & IIS OWIN (i.e. Katana) ● Self hosting: (using WCF hardened core) WPF Windows service console app, any other .NET app ● Memory hosting: whole pipeline running in memory @filip_woj
- 12.
- 13. OK, but whywould I need it? ● New HTTP object model ● Work with HTTP concepts ● HTTP as a fully fledged *application* protocol ● Facilitates both REST & RPC ● Async from top-to-bottom @filip_woj
- 14.
- 15. Async examples ● Handlers: Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken); ● Filters: Task<HttpResponseMessage> ExecuteActionFilterAsync(HttpActionContext actionContext, CancellationToken cancellationToken, Func<Task<HttpResponseMessage>> continuation); ● Formatters: Task WriteToStreamAsync(Type type, object value, Stream writeStream, HttpContent content, TransportContext transportContext); Task<object> ReadFromStreamAsync(Type type, Stream readStream, HttpContent content, IFormatterLogger formatterLogger); @filip_woj
- 16. New HTTP objectmodel ● Strongly typed HttpResponseMessage ● Strongly typed HttpRequestMessage ● Strongly typed Headers ● Strongly typed HttpContent ● No more “angle brackets coding” & magic strings ● Asynchronous API ● Client-server symmetry @filip_woj
- 17. HTTP status codes ● 1xx – Informational ● 2xx – Successful ● 3xx – Redirection ● 4xx – Error on the client side ● 5xx – Error on the server side @filip_woj
- 18. HTTP headers –request ● Request headers (selected) – Accept, Accept-Language, Accept-Encoding – Authorization, Cache-Control, Range – If-Match, If-Modified-Since, If-Range ● Content headers (selected) – Allow, Content-Encoding, Content-Language – Content-Length, Content-Type, Expires – Last-Modified @filip_woj
- 19. HTTP headers –response ● Response headers (selected) – Accept-Ranges, Connection – Cache-control, Date, Etag – RetryAfter, Warning, Location ● Content headers (selected) – Allow, Content-Encoding, Content-Language – Content-Length, Content-Type, Expires – Last-Modified @filip_woj
- 20.
- 21. RPC ● /api/GetTeams ● /api/GetTeam?id=1 ● /api/GetPlayersByTeam?id=1 ● /api/AddTeam ● /api/UpdateTeam ● /api/UpdateTeam?id=1&name=”Leafs” ● /api/DeleteTeam?id=1 @filip_woj
- 22.
- 23. REST ● representational state transfer ● architecture for building systems by Roy Fielding ● advantages: stateless cachability hypermedia driven (client needs to know one link, usually) scalability everything addressable with URI @filip_woj
- 24. From: presentation by@alexbeletsky @filip_woj
- 25. HTTP verbs ● Represent CRUD on a resource: - GET: read, cachable, retreives a resource - POST: non-cacheable, creates a resource - PUT: updates a resource, safe to call multiple times - DELETE: deletes a resource, safe to call multiple times ● Can also use others i.e. PATCH (partial update of a resource) @filip_woj
- 26. RESTful ● GET /api/teams ● GET /api/teams/1 ● GET /api/teams/1/players ● POST /api/teams ● PUT /api/teams/1 ● DELETE /api/teams/1 @filip_woj
- 27. First API –GET public class TeamsController : ApiController { private readonly IUnitOfWork _uow; public TeamsController(IUnitOfWork uow){ _uow = uow; } public IEnumerable<Team> Get() { return _uow.Teams; } public Team Get(int id) { var team = _uow.Teams.FirstOrDefault(i => i.Id == id); if (team == null) throw new HttpResponseException(HttpStatusCode.NotFound); return team; } @filip_woj
- 28. First API –POST public void Post(Team value) { if (!ModelState.IsValid) throw new HttpResponseException(Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState)); _uow.Teams.Add(value); _uow.SaveChanges(); } @filip_woj
- 29. First API –PUT public void Put(int id, Team value) { if (!ModelState.IsValid) throw new HttpResponseException(Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState)); var team = _uow.Teams.FirstOrDefault(i => i.Id == id); if (team == null) throw new HttpResponseException(HttpStatusCode.NotFound); team.League = value.League; team.Name = value.Name; _uow.SaveChanges(); } @filip_woj
- 30. First API –DELETE public void Delete(int id) { var team = _uow.Teams.FirstOrDefault(i => i.Id == id); if (team == null) throw new HttpResponseException(HttpStatusCode.NotFound); _uow.Teams.Remove(team); _uow.SaveChanges(); } } @filip_woj
- 31. Demo: first API @filip_woj
- 32. Content negotiation ● Dynamically deciding the media type ● Same data can be represented in various formats: - JSON – XML – CSV – binary – anything to what your data can be serialized/deserialized from ● In Web API done with MediaTypeFormatters @filip_woj
- 33. Content negotiation inWeb API ● Web API uses the following precedence: 1. MediaTypeMapping ● /api/resource.json, /api/resource?format=json 2. Accept headers ● Accept: application/json 3. Content type header ● Content-Type: text/xml 4. MediaTypeFormatter order & check whether a formatter can serialize/deserialize a given type @filip_woj
- 34. So how mymodel gets serialized? ● Out of the box supports: - XML (DataContractSerializer / XmlSerializer) - JSON (DataContractSerializer / JSON.NET) - Form values (from client only, one-way) @filip_woj
- 35. Extending content negotiation ● Very easy, some examples: - BSON (binary JSON) - ServiceStack.Text (instead of JSON.NET) - MessagePack - Mobi (returning ebook!) - RSS/Atom - Supporting Razor views (text/html) @filip_woj
- 36.
- 37.
- 38. Message Handlers ● “Russian doll model” ● run first and last ● process raw HttpRequestMessage & HttpResponseMessage ● Ideal for generic tasks such as authentication or API usage logging ● Can be global or route-specific @filip_woj
- 39. Client-server symmetry By: Henrik Frystyk Nielsen ● Message handlers can run on server and on the client ● HttpServer is a message handler itself @filip_woj
- 40. Filters ● Conceptually same as in MVC ● Cached for performance (unlike MVC) ● Pre-action processing of raw HttpRequestMesage ● Post-action processing of raw HttpResponseMessage @filip_woj
- 41. Controllers ● Represent your API resources ● Similar as in MVC ● Routing engine determines which controller to use ● Supports nested resources @filip_woj
- 42. Dispatching actions ● By default HTTP verb based (RESTful) ● Actions matched: ● by prefix (i.e. GetAll, GetById) or ● by action attribute (i.e. [HttpPost]) ● Can be changed to action based (RPC style) @filip_woj
- 43.
- 44. Anything else? ● TDD, BDD – whole pipeline can run in memory ● Async from top-to-bottom – scales well ● Simple: figure out your resources, and build around them ● Next release (Feb 2013) will have OData support ● Integrates with SignalR @filip_woj
- 45. Demo: first API– self hosted @filip_woj
- 46. Demo: first API– memory hosted @filip_woj
- 47. Demo: adding BSONformatter @filip_woj
- 48. Demo: P2P inWPF @filip_woj
- 49. Follow these guys @frystyk @glennblock @tourismgeek @darrel_miller @aliostad @benfosterdev @pwalat @pmhsfelix @filip_woj
- 50.
Editor's Notes
- #4 – beta in Feb 2012, RC in June 202 – open source, just like Mvc, Entity Framework, part of azure – i'm part of web api advisory board, assembled by Dan Roth from Microsoft, we meet every 2 weeks and discuss the new development ideas & general direction of the product, – chief architect on the project is Henrik Nielsen, who in the early 1990s at CERN in Geneva, co-authored the HTTP spec and co-created th world wide web with Tim Berners Lee and the team
- #5 – ASP.NET has a bad reputation, as being an unnecessary abstraction over the web and being HEAVY – MVC has changed that a bit, but still the perception remains – especilly now with the rise of new sexy technologies such as node.js or earlier rails – i'd like to show you that MS can also make stuff that's good for the web, and lightweight
- #6 – the root for HTTP services in the MS stack lies in WCF, and was very poor, with complex configuration, a lot of “angle bracket coding” and lots of runtime errors – this evolved with a few “out of band” releases such as REST starter kit, and eventually became WCF Web API – WCF Web API was already open source – then WCF and ASP.NET teams were merged and the result was Web API, as it adopted some concepts from MVC – this lowers the barriers of entry for MVC developers, who'd instantly be familiar with the Web API way of building services because they know it from MVC
- #8 – content negotiation – so the process of determining the response media type based on request message – and opposite determining how to read the payload of the incoming request – message handlers – which run first and last in the stack and allow you to work with raw HTTP objects – RESTful approach (as opposed to traditional RPC) – the configuration process of Web API is based on how configuration was done in WCF web api and does not require XML files
- #9 – the concept of model binding. While Web API does model binding completely differently than MVC, conceptually the task is the same – controller centric approach, where each resource (also called API endpoint) is a controller – ASP.NET routing; the routetable has been ported so that it can work outside of ASP.NET as well – filters which run before and after an action – dependency injection was already supported in WCF Web API, but they way it's implemented, almost mirrors how it's done ine MVC
- #10 – here is the problem – naming things is difficult, and in the case of Web API it creates lots of problems
- #11 – Web API can be hosted in IIS, on top of ASP.NET but it's not a requirement – Web API is a fully fledged framework, not just API tool. You can do whatever you'd expect from a web framework including handle binary files, handle state if needed, even serve HTML files with Razor engine
- #12 – 3 hosting options – web hosting is on top of ASP.NET and can be in IIS but it doesn't have to, it can also be hosted with any OWIN (open web interface for .NET) implementation such as Katana. I blogged about that – self hosting means spinning up a web server inside of the managed process we are running (using WCF hardened core which wraps around httplistener). This can be done from any .NET app – memory hosting means running th whole pipeline in memory without using netowrk hardware. You can create an instance of HttpServer and send data from HttpClient directly to it in memory
- #13 – does not have the baggage of .NET 1.1 on whch Web Forms and MVC are built!
- #14 – new HTTP programming model has been introduced in .NET 4.5, but Web API team backported a lot of the stuff to .NET 4.0 – replaces old stuff from .NET 1.1 and System.Web, which started to show its age, and a lot of its concepts were synchronous and string based – HTTP as a first class citizen; – you get to embrace HTTP and you get a lot of things for free such as caching at various intermediary levels. You also don't have to reinvent the wheel with operation statuses and such – with REST you follow the standards – client and server work with same objects – whole pipeline is async (as opposed to MVC or other frmwks). In MVC controllers are async but not pipeline. This means it scales well
- #15 – NancyFX, ServiceStack – built around IhttpHandler and are fully synchronous
- #16 – symmetrical between client and server – pretty much everything you can imagine about HTTP – from headers, through body content to response & request themselves are strongly typed – no static configuration – fully asynchrnous – not just for sending messages, but even for tasks such s reading the request.response body – very flexible in terms of extending media type support
- #17 – symmetrical between client and server – pretty much everything you can imagine about HTTP – from headers, through body content to response & request themselves are strongly typed – no static configuration – fully asynchrnous – not just for sending messages, but even for tasks such s reading the request.response body – very flexible in terms of extending media type support
- #22 – traditional model, familiar from perhaps ASMX or MVC – call server methods by name – gets messy
- #23 – is shit
- #24 – REST is probably the most verused buzz word in the web world – but has several advantages, mainly cause it's standard – STATELESS – no session, so for example as an authenticated user, you have to sign requests and reauthenticate each time – true REST should be hypermedia driven with a one entry point to the application and navigational properties – you build around HTTP VERBs NEXT SLIDE
- #26 – cornerstone of any REST system – standard
- #27 – now we can see the same API as before, but in a RESTful manner. You can see it's much cleaner, readable and maintainable – also much more discoverable
- #33 – content negotiation is a two-way process, it can determine the format (media type) of a response based on the request – it can also determine how to deserialize the incoming request – there are countless examples of media types, two most popular ones are XML & JSON – media type don't have to support read and write for example RSS is read only
- #34 – media type mappings allow you define extension i.e. .json or querystring paramter i.e. ?format=json – accept headers are sent by default by i.e. The browser 'text/html' – content-type headers come in play when client sens in some data, for example on POST or PUT. If there is data coming back, it wil be symmetrically formatted – finally the mediatypeformatter order and JSON is default. Web API will also check if the given Type is supported by the formatter. Like we said, RSS is write only and FormData read only
- #35 – out of the box web API has 3 formatters, but form is read only – XML & JSON are universal
- #36 – when it comes to reading data is a bit more compllicated since data can also come from URI – QS and route data – this type of data is read using model binders not media type formatters – formatters only scan the body, normally for complex types (eve though primitives can also be sent) – body in Web API can only be read once, that's for performance reasons. – in MVC the whole body was buffered into memoery. Now imagine a request that has an body of 400MB of upload data – can cause server instability
- #37 – web api formatter collection can be super easily extended
- #38 – the whole point is to abstract away the request/response format from the actual action which should work with CLR types
- #39 – what's important here are the colors. – message handlers run before anything else, they process raw request and are perfect for things like API usage logging or authentication – handlers can run on specific routes only if needed – think public/prvate API – filters run before controller actions – then the action runs – and the process reverses – so whatever ran first, runs last All in all this is called the russion doll model
- #40 So maybe we dont need the chart
- #41 – mesage handlers dont exist in MVC – suitable for generic tasks applicable for entire or part of your API – filters do the same except they apply to individual action – architecturaly, handlers are singletons so it creates additional considerations when it comes to DI and so on
- #43 – filters allow you do to pre/post processing – perfect for applying repeated logic such as checking model state or checking the incoming request for null values – you can have many filters
- #45 – the default dispatched is RESTful – your actions don't have to be named as HTTP verbs, but should be prefixed by the HTTP verb – alternatively you can use the attribute
- #46 – in the original ASP.NET web forms nothing was extendible it then started changning, later versions were much better – the big strength about Web API is that you can replace almost everything in the framework – entire content negotiation engine (remember the slide where i showed the order of precendece) this entire logic can be scraped. – model binding can be customized, and changed to i.e. MVC style binding if you want – you can plug in any DI container – you can plug in any logging framework, even for the internal tracing
- #47 –
- #48 – because of memoery hosting, Web API facilitates very well TDD, BDD – asynchrony is very important as it increases your overall thgroughput – beauty in simplicity – Odata is MS data exchange protocol. I.e. Netflix API supports it and it's great for querying data – works well with signalr for realtime apps, so you can have an app which i.e. Adds an order through POST and immediately notifies the connected clients about the new order