“Truly understanding ASP.NET Web API” sau hățișul acronimelor

[rant on]
Cine a urmărit blogurile în ultima vreme a observat că mai toată lumea vorbește de ce a aparut nou in .NET 4.5, și mai ales de ASP.NET Web API.

Cine sapă de mai multă vreme pe ogorul .NET probabil și-au zis: “not again”..
Doar în lumea Microsoft, când vine vorba de aplicații distribuite, a avut:
- DCOM,
- .NET Remoting
- ASP.NET Web Services (.asmx) si WSE,
- WCF,
- WCF Data Services (fost ADO.NET Data Services, fost Astoria)
- WCF RIA Services (fost .NET RIA Services)

- WCF+WebHTTPBinding (în .NET 3.5),
- WCF REST Starter Kit
- WCF WebHTTP Services (în .NET 4.0)
- WCF Web API
- ASP.NET MVC REST services
Probabil cineva de la Microsoft cand a văzut ultimele 5, a zis .. wtf? și s-au hotărât să le unifice:
- ASP.NET Web API

(Și asta fără să mai amintesc alte API-uri pentru TCP/IP sockets, WebSockets etc..)

Confusing? Suficient – daca WPF promitea să unifice ASP.NET Web Services respectiv .NET Remoting, și oarecum a reușit, mai nou vedem o aparentă explozie de API-uri.
E ceva în neregulă cu WCF? Depinde de mulți factori.

WCF a încercat să abstractizeze diversele protocoale intr-o mare masură, și să fie cât mai flexibil – a reușit asta destul de bine și arhitectura internă e destul de elegantă, însă cu prețul unei complexităti care a duscurajat mulți programatori care nu aveau nevoie de ceva prea sofisticat. La asta s-au mai adăugat alți factori mai mult sa umai puțin subiectivi:
- SOAP si SOA – frumoase în teorie, dar care nu au avut succesul sperat înafara mediului “enterprise”
- AJAX si SOAP/WSDL – complexitatea SOAP si WSDL nu au fost cea mai bună alegere pentru noul val de aplicații web care vroiau un API simplu, cu un payload cat mai mic (capitol la care XML nu strălucește)
- deși destul de răspândit, suportul pentru SOAP și puzderia de specificații WS-* nu e nici la ora actuală universal sau uniform așa cum se spera (în primul rând datorită complexitătii). Mulți programatori au descoperit că nu au decât rareori nevoie multe din protocoalele WS-*.

Treptat, s-a conturat un curent care l-aș numi “back to basics” – lumea a realizat că la ora actuală ne putem baza pe un numitor comun: TCP/IP si HTTP cand vine vorba interoperare între diverse aplicații pe web. Deși nu era o idee nouă, mulți au re-descoperit faptul ca HTTP-ul e un application-level protocol, și ca ‘HT’ din denumire (hyper-text) nu se referă doar la HTML.
[rant off]

Dar destul cu filozofia. Încercând să înțeleg care e locul ASP.NET Web API în toată această poveste, am descoperit că trebuie să fac un mic reset și să înțeleg următoarele noțiuni (care par elementare, dar nu sunt):

• HTTP ca application-level protocol:
  - Pluralsight HTTP fundamentals course (Scott Alen): http://www.pluralsight-training.net/microsoft/Courses/Description?courseName=xhttp-fund (l-am văzut într-o zi când îl ofereau gratis, dar merită banii)
• REST
  - http://en.wikipedia.org/wiki/Representational_state_transfer - multă lume pleacă de la articolul de pe Wikipedia, dar se pare că la fel de multă lume nu înțelege REST cu adevărat, când e util si când nu, și de ce multe API-uri sunt doar “REST-like”
• Clean URIs: http://www.w3.org/Provider/Style/URI.html
  
• HATEOAS sau REST done right – probabil cea mai interesantă parte în toata povestea asta:
  - http://en.wikipedia.org/wiki/HATEOAS
  - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
  - http://stateless.co/hal_specification.html
  
• Un articol foarte bun care sintetizează diversele stiluri de web services:
  Richardson Maturity Model - http://martinfowler.com/articles/richardsonMaturityModel.html
  
• Și câteva articole interesante care încearcă să raspundă la intrebarea: “Why Web API”:
  - http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my-two-cents-on-the-subject.aspx
  - http://mattmilner.com/Milner/Blog/post/2012/02/28/WebAPI-or-WCF.aspx
  - http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

Unde aș folosi ASP.NET Web API – în multe cazuri: aplicații Silverlight, aplicații web ce folosesc la greu AJAX și/sau HTML5, web services publice care vor avea clienți pe mai multe platforme sau limbaje.

Unde nu? La comunicarea, într-un intranet, între diversele componente server-side ale aceleiași aplicații, și unde contează performanța și unde nu se pune problema expunerii acelui web service către “publicul larg”.
În cazul în care un web service urmează a fi consumat de către un client care nu are suport facil pentru REST-style web services.
Dacă e nevoie de diverse features mai avansate, oferite doar de WCF sau dacă am nevoie de OData support (încă nu știu în ce masură Web API are suport pentru OData ușor de folosit).

Revenind la denumiri, pentru cine nu a urmarit zi de zi genealogia lui ASP.NET Web API: acesta e succesorul WCF Web API, care e succesorul lui REST Starter Kit, și intentioneaza să înlocuiască ASP.NET MVC REST services.
WCF in sine rămâne, la fel și WCF Data si RIA Services (au un target un pic diferit).

Morala ar fi – odată asimilate conceptele de bază (HTTP, REST etc), nu mai e o tragedie când se schimbă diversele frameworkuri odata la câtiva ani.

User-agent confusion, sau o poveste despre genealogie în lumea browserelor

Dacă v-ati întrebat vreodată ce au băut developerii care au produs un web browser ce la fiecare request raspunde cu un cârnaț de genul:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11

sau

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

o explicație interesantă și cu puțin umor se găsește la:
http://webaim.org/blog/user-agent-string-history/

Învățând engleza cu Entity Framework

Tocmai mă jucam azi cu nou-apărutul Entity Framework 5 beta – creez o clasa Person, merg in DB și creez o tabela Persons, un DbContext și mă aștept ca EF code-first să deducă maparile pentru mine (convention over configuration), cum a făcut-o și până acuma.
Mă asigur ca EF mă lasă să-mi creez singur baza de date:
Database.SetInitializer(null);
La execuția primului query însă, o excepție:

...
InnerException: System.Data.SqlClient.SqlException
Message=Invalid object name 'dbo.People'.
Source=.Net SqlClient Data Provider


wtf? Se pare că EF știe engleză mai bine decât credeam, și știe că forma uzuală a pluralului la ‘person’ e ‘people’, nu ‘persons’.

“Vinovatul”? PluralizingTableNameConvention - convenția implicită folosită de EF code-first când încearcă să deducă numele tabelei plecând de la numele clasei.

În altă ordine de idei, customizable conventions e o chestie foarte utilă când cineva are de-a face cu zeci de tabele și sute de field-uri, iar naming convention-urile sunt impuse din exterior de vreun DB admin. EF customizable/pluggable conventions nu au intrat in versiunea finala a EF 4.1 (erau prin EF Feature CTP5) – nu am verificat încă dacă in versiunile mai recente (4.3) au reușit să le reintroducă.

VS11 beta – câteva impresii la cald

VS11 beta ultimate – cateva impresii aleatoare la o privire din exterior (nu un review riguros):(Nu voi repeta tot ce a aparut nou sau ce s-a schimbat – sunt altii care o fac mult mai bine: http://blogs.msdn.com/b/jasonz/archive/2012/02/29/welcome-to-the-beta-of-visual-studio-11-and-net-framework-4-5.aspx )

- installer: splash screen-ul apare si.. stă acolo câteva minute bune, fără nici un progress bar

- nu permite selectarea feature-urilor ce se doresc instalate

- gri – minimalist, dar un pic deprimant

- in installer, de la clepsidra s-a trecut la cercul rotitor si acuma la punctele ce aluneca de la stanga la dreapta precum in Windows Phone 7 – nu arata rau, macar lasa mai bine impresia ca aplicatia ronțăie ceva.

- e a treia oara cand MS Client Forefront Security ma intreaba deca sa-i dau voie installer-ului sa-si faca de cap

- startup time-ul cam la fel ca la VS2010

- icon-urile din nou minimaliste, monocrome stil WP7 – s-ar putea sa arate bine marite de 2-3 ori, dar pe un monitor normal, la marimea implicita, mai mult incurca si sunt greu de folosit pentru a identifica un element. Normal, un programator cu experienta va folosi doar shortcut-urile, dar rolul icon-urilor tocmai asta era, sa ajute pe cineva care mai foloseste si mouse-ul, caz in care un pic de culoare ajuta mult.
Cineva la MS a luat deviza “content over chrome” din WP7 prea ad-literam..

- Tools/Options/Environment/Fonts&Colors se incarca parca o idee mai repede, dar tot lent..

- cel putin la noile proiecte, Solution Explorer arata precum Solution Navigator-ul (care pana acum era in Productivity Power Tools) si combina Solution Explorer, Class View, Object Browser, Call Hierarchy, Navigate To si Find Symbol References all-in-one. Inca nu m-am obisnuit cu el, da’ poate e util uneori.

- titluri la panels cu majuscule: nu vad rostul la asa ceva..

- cel putin la un web service nou creat (WCF), la Run tine cont de browser-ul default (Chrome) si numele browser-ului apare in toolbar ca sa nu am surprize – nice

- ferestre precum Debug/Exceptions si Debug/Attach to process in continuare nu se pot redimensiona.

Totusi, daca privim dincolo de “skin”, inbunatatirile sunt reale.

CallerMemberName – mai bine mai târziu decât niciodată

Printre avalașa de noutăți aduse de VS11 beta, .NET 4.5 beta, C# 5.0 beta s-a strecurat un mic feature care ar fi făcut viața mai ușoară la mulți programatori dacă ar fi apărut cu 10 ani în urmă: CallerMemberNameAttribute

Oricine a programat în WindowsForms sau WPF își aduce aminte cât de boring era să se implementeze INotifyPropertyChanged pentru toate property-urile unei clase care avea nevoie de data binding:

public string FirstName
{
get { return _firstName; }
set { _firstName = value; NotifyPropertyChanged("FirstName"); }
}

mai ales când aveam de-a face cu 30- 40 de clase, fiecare cu o gramadă de properties.

Genul ăsta de cod venea cu două probleme:
- repetitive code
- nume de properties hardcodate ca string-uri, deci error prone și mai greu de refactorizat (pentru cine nu avea tooluri gen Resharper, care se uită și în stringuri)

Desigur, soluții există: generatoare de cod, lambda expressions, tehnici gen AOP (ex. folosind PostSharp), code weaving (http://code.google.com/p/notifypropertyweaver/), stack walking etc, dar toate implică un oarecare efort până sunt implementate într-un proiect nou..

CallerMemberName e un atribut, care se poate aplica la un parametru opțional al unei metode, cu o valoare default specificată, și care va putea fi folosit pentru a pasa “automat” numele caller-ului (metodă, constructor, etc.). Desigur, în esență e un sintactic sugar, dar care ne ușurează munca:

public string FirstName
{
get { return _firstName; }
set
{ _firstName = value;
if (_firstName != value) { NotifyPropertyChanged(); }
}
}
// ...

protected void NotifyPropertyChanged([CallerMemberName] string property = null)
{
var tempEventCopy = PropertyChanged:
if (tempEventCopy != null)
{
tempEventCopy(this, new PropertyChangedEventArgs(property));
}
}
public event PropertyChangedEventHandler PropertyChanged;

Desigur, ramane problema codului repetitiv, dar refactoring-ul se simplifică si erorile de typing dispar.
Un alt avantaj e la capitotul performanță – față de tehnici gen stalk walking sau chiar lambda expressions, în acest caz totul se întâmplă a compilare.
Față de tehnici gen AOP și code weaving are avantajul că nu trebuie să ne amestecăm in procesul de build, instalăm componente suplimentare pe build server etc.

Skype (beta) pe WP7

După ce Skype a apărut pe iPhone, Symbian si Android de ceva vreme, era și timpul ca Microsoft să vină cu o versiune pentru Windows Phone 7:

Voi reveni cu câteva impresii după ce o mai testez un pic..

LE: M-am mai jucat un pic cu Skype-ul pe un HTC7Pro: partea bună: text, voice și video calling funcționează (oarecum).

Cum era de așteptat la o versiune beta, încă scârție multe lucruri: nu se conectează din prima întotdeauna, se mai deconectează din senin, uneori butoanele de answer sau reject voice call nu răspund, în chat textul nu e aliniat chiar cum trebuie (plus o zonă albă goală în baza ecranului, nefolosită), uneori în landscape mode când folosesc keyboard-ul fizic, text-box-ul nu se poate focusa.

Nu am vazut vreo opțiune ca să ruleze în background sau suport pentru push notifications, deci cam trebuie ținut pornit și în foreground pentru a primi apeluri.

Încă suportul pentru landscape orientation e parțial, deși ar fi util pentru cine are și tastatură fizică la smartphone; pe HTC7Pro-ul meu audio-ul merge doar pe loudspeaker din cate se pare.

O listă cu “known issues” se găseste pe site la Skype: http://blogs.skype.com/garage/2012/02/skype_beta_for_windows_phone_w.html  și forumul la: http://community.skype.com/t5/Windows-Phone-BETA/bd-p/Windows_Phone

Să sperăm că vor trage tare până la release-ul final și vor veni cu o versiune stabilă, cea actuală aș numi-o mai mult CTP/alpha.

 

Braunschweig – Schloss Richmond – Sudsee

Braunschweig – Schloss RIchmond – Sudsee, a set on Flickr.

Între iarnă și primăvară, un colț de liniște la sud de Braunschweig..