Av og til skal det være ganske vanskelige å finne noe fornuftig på nettet - selv med Google ;)

Skal du konsumere rest-baserte tjenester i .Net - kan du enten utføre HTTP-Request direkte mot tjenestene med accept json(e.l.) - eller gjøre det det på følgende måte(noe som jeg synes blir mye bedre):

WebChannelFactory<IBookmarkService> cf = new WebChannelFactory<IBookmarkService>(
    new Uri("http://localhost:55555/BookmarkService.svc"));
IBookmarkService channel = cf.CreateChannel();
Bookmarks bms = channel.GetPublicBookmarks("WCF");
foreach (Bookmark bm in bms)
    Console.WriteLine("{0}\r\n{1}", bm.Title, bm.Url);

For å kunne konsumere REST-tjenester på denne måten blir du nødt til å opprette et interface selv på klientsiden, noe som i mange tilfeller kan være verdt innsatsen.

Hele oppskriften finner du på "A Guide to Designing and Building RESTful Web Services with WCF 3.5" under "Consuming RESTful Services with WCF"

http://msdn.microsoft.com/en-us/library/dd203052.aspx , A Guide to Designing and Building RESTful Web Services with WCF 3.5.

Les mer på:
http://blogs.msdn.com/b/pedram/archive/2008/04/21/how-to-consume-rest-services-with-wcf.aspx 
http://blogs.msdn.com/b/kaevans/archive/2008/07/26/creating-a-rest-twitter-client-with-wcf.aspx

Hadde litt diskusjoner rundt bruk av extension metoder på jobben i dag - og særlig med tanke på hvor det er fornuftig å bruke dette, og også hvordan.

Vi kom frem til en grei "konklusjon" om du kan kalle det med følgende retningslinjer:

• Extension metoder skal tilby generisk funksjonalitet som er relevant i mer enn en kontekst.
• Extension metoder skal tilby utvidet funksjonalitet til interface, og ikke til konkret type. Er det nødvendig å spesifisere en konkret type på extension-metoden, bør det vurderes om funksjonaliteten som tilbys heller bør være i implementasjonen av selve typen og ikke som en extension. 
• Unntaket fra regel om å alltid lage extension for ett gitt interface og ikke en konkret type - er når du har en type du ønsker å utvide funksjonaliteten til, men ikke har tilgang til å faktisk gjøre dette. I slike tilfeller er det godtatt å utvikle extensionmetoder for en konkret type som utvider funksjonaliteten til denne typen. Eksempler på dette kan f.eks. være for å utvide tredjeparts API eller typen "objekt". Det bør uansett vises forsiktighet ved bruk av extension-metoder da vedlikehold av slik "ekstern" funksjonalitet kan fort vise seg å medføre mer overhead enn f.eks. å følge patterns av typen adapter, fasade e.l.

Twitter-quote of the day:

tuxbear Ole - André Johansen
@israrkhan I suggest putting all your code in Extension Methods for Object.

Sjekk også ut:
http://codebetter.com/blogs/gregyoung/archive/2007/12/05/a-use-for-extension-methods.aspx

Adapter pattern:
http://en.wikipedia.org/wiki/Adapter_pattern

Facade pattern:
http://en.wikipedia.org/wiki/Facade_pattern

Edit: Ole-André hadde et annet scenario hvor bruk av extension metoder kan virke fornuftig:

En annen gyldig bruk av extension methods, sånn jeg ser det, er for å gruppere funksjonalitet. Hvis man for eksempel har et objekt som er mye brukt i en kodebase, kan det være befriende å gruppere funksjonaliteten som extension methods i forskjellige namespaces.

For eksempel om man har et Person-objekt, og man vil ha pensjon og forsikringsmetoder i forskjellige "pakker" som man kan inkludere og bruke på Person. person.BeregnPensjon(), og person.BeregnForsikringsPremie() kan leve i to forskjellige namespaces. Da kan de som jobber med pensjon slippe å se forsikringslogikken.

Extension Methods; handle with care