At this rate I’ll finish posting my conferences notes sometime around the start of next year’s DevConnections conference. Anyhow, here are my notes from Day Three of the DevConnections 2012 conference:
Leveraging Web API to Reach Many Client Platforms – Brian Noyes, IDesign, Chief Architect
- Leverage ASP.NET Web API to reach many clients (exposing and consuming HTTP and REST services)
- New services stack; evolved from WCF, no WCF anywhere, except for standalone versions.
- WCF meant to be interop. SOAP is “theoretically” supposed to interopable, but not truly. Ideal for .NET to .NET communication.
- WCF Web API on .NET 4 is an “architectural abomination” created to expose HTTP.
- Complexity of WCF hindered adoption and use.
- Web API designed to address above problems with WCF. The surface of Web API didn’t change, but underpinning changed substantially. It is own stack, not using any WCF. Web API in IIS is pure ASP.NET. Standalone Web API runs in WCF hosting environment.
- Term “REST” is misused a lot; comparing REST vs. SOAP is like comparing apples vs. oranges. REST is an architectural style. SOAP is a protocol.
- REST fully embraces HTTP. SOAP is always HTTP POST; with REST you can use your HTTP verb of choice: POST, GET, PUT, DELETE, MERGE (oData). HTTP Headers are ignored by SOAP.
- Web APIs or Web Http services are not necessarily REST services. Call it Web API, not REST.
- Services are a flavor of MVC Controller. ApiController is the base class.
- Web API is simpler than WCF: no config, no attributes, convention over configuration, automatic formatter selection.
- Web API supports oData query syntax in the URL.
- By default, Web API uses JSON, serialized payload, much more lighter weight.
- Pedro Felix – check out his blog posts re: underlying architecture for Web API.
- Consuming Web API – old style: WebClient and HttpWebRequest. New style: .NET 4/4.5/WinRT – HttpClient.
- Leastprivilege.com – framework for security on Web API.
Doing More with LESS for CSS – Todd Anglin, Telerik, VP of HTML5 Web & Mobile Tools
- There are 15 browser prefixes, only four of them matter: -ms-, -moz-, -webkit-, -o-
- Makes it easier to target different browsers. Supports global variables. Easier to do DRY CSS. Simplified complicated style hierarchies.
- LESS is a CSS Preprocessor. Adds capabilities like variables, operations, mixins for reuse, nested rules.
- LessCSS.org
- SASS is another CSS precompiler.
- LESS does not: add CSS support, detect CSS, add runtime overhead.
- LessCSSIsMore.com
- Variables: Reusable values, can only be defined once; are a constant; @variable name. Can have variables inside variables.
- New way of commenting within CSS: JS style comments. “//”
- Anything that is not valid CSS will not be output to CSS file.
- Can execute JavaScript in a LESS file.
- Operations: In-line CSS operations – any #, color or variable.
- Mix-ins: encapsulated CSS rule sets. Reusable, can accept parameters, solution to CSS prefixes.
- LESSElements.com – collection of mixins.
- Nested Rules: simplifies complicated CSS rule naming; selectors. Visual way to understand format.
- Different ways to use LESS:
- 1) Dynamic Parsing Client-side using JavaScript: what KendoUI does, fastest to implement, client-side. [runtime]
- 2) Dynamic Parsing server-side: ASP.NET Handler = dotless, DLL only sends CSS. [runtime]
- 3) Design-time/Build-time Parsing: Best for production apps. Chirpy for Visual Studio. Runs parser in the background.
