SharePoint

SP2013: CSOM

26 oktober 2012

In mijn vorige blogpost schreef ik al even kort over het nieuwe Client Side Object Model (verder: CSOM). Dit nieuwe model geldt als vervanger voor client.svc in SharePoint 2010. Omdat al het programmeerwerk straks tegen dit nieuwe model moet gaan kletsen, wil ik in deze post een korte uitleg geven van het nieuwe model versus de ‘oude’ opties in 2010.

2010

Laten we  beginnen om even terug te kijken op de API opties in 2010. Iedere ontwikkelaar die wel eens client side code heeft geschreven zal weten dat we client side de volgende opties tot onze beschikking hadden:

[listdot]

[/listdot]

Deze modellen brachten een hoop moois, maar zijn zeker niet perfect. Om een aantal zaken te noemen:

[listdot]

  • De client side modellen kunnen (veel) minder dan het server side object model.
  • De client side modellen hebben niet allemaal dezelfde mogelijkheden.
  • De client side modellen werken niet op dezelfde manier.

[/listdot]

Ontwikkelaars die het client model goed kennen zullen weten dat het eigenlijk wrappers zijn voor /_vti_bin/client.svc , een webservice aan de server kant. Hoewel het mogelijk is om directe calls te maken naar client.svc, wordt dit niet aangeraden / ondersteund. We waren dus beperkt tot het gebruik van een van de 3 bovenstaande wrappers.

De cloud

Met de overgang naar de cloud (SharePoint Online / Office 365) probeert Microsoft ontwikkelaars zoveel mogelijk van het server object model af te helpen. Dat kun je immers niet gebruiken in de online omgeving, dus moeten er goede alternatieven zijn. De bovengenoemde nadelen van de oude client side modellen zorgden voor een mindere mate van acceptatie onder ontwikkelaars. Veel mensen gebruiken de modellen echt alleen wanneer het niet anders kan. En vaak zorgen de beperkingen ervoor dat er toch nog een extra webservice met aanvullende functionaliteit binnen de farm gedeployed wordt. En daarmee verdwijnt het cloud scenario wat Microsoft zo graag ziet al snel uit de optielijst.

_api

Dus hebben de engineers uit Redmond hier een oplossing voor gezocht en grotendeels gevonden. Een nieuwe API, gebaseerd op ODATA (Open Data Protocol) moet een hoop van onze zorgen wegnemen. Je bereikt de api door simpelweg /_api achter het adres van je site te plaatsen.

Laat me beginnen met het noemen van een aantal voordelen:

[listdot]

  • De nieuwe API mag je ook rechtstreeks aanspreken.
  • De nieuwe API biedt veel meer functionaliteit.
  • Alle API functionaliteit is gegroepeerd onder hetzelfde endpoint. Zo vind je search (voorheen een aparte webservice) nu via /_api/search.
  • Je kunt de API aanroepen met REST calls, voor velen wel bekend inmiddels.

[/listdot]

In mijn vorige post plaatste ik al de volgende afbeelding:

Hieruit blijkt duidelijk dat alle API calls nu door dezelfde laag lopen. Dat betekent dat je nog maar 1 endpoint in je client software hoeft te configureren. Dat betekent dat alle calls nu eenzelfde werking hebben en dat die calls (in REST syntax) te gebruiken zijn vanuit .NET, JavaScript, Silverlight of welk platform dan ook. Dat laatste is natuurlijk ook een groot voordeel voor integratiescenario’s met andere platformen!

Overigens betekent dit niet dat de wrappers aan client kan verdwijnen, die zijn er nog steeds. Dus je kunt nog steeds met managed code werken in .NET zonder dat je alle API calls zelf moet gaan uitschrijven. Een win-win situatie wat mij betreft.

Aan de slag

Het heeft weinig zin om op deze plaats een complete uitleg te gaan geven van de mogelijkheden die je hebt met het CSOM. Dat is ten eerste teveel stof, ten tweede is die informatie natuurlijk gewoon beschikbaar op MSDN. Dus geef ik je een aantal linkjes waar je voorlopig wel even vooruit moet kunnen:

[listdot]

[/listdot]

Veel succes! Laat ook vooral een berichtje achter wanneer je wat hebt gemaakt met het nieuwe CSOM, ik ben benieuwd naar jullie meningen.

 

You Might Also Like

Geen reacties

Plaats een reactie