Den andra sessionen hölls av NPR från vilka vi lånat COPE-tänket. En sammanfattning av förra årets NPR-session finns här.

Utmaning: få ut innehåll i olika kanaler.

Principer:
– Bygg inte ett stort system – koppla ihop många mindre komponenter
– COPE (se tidigare inlägg)
– CMS och presentationslagret är olika saker
– ATOM (Storyn är NPR:s atom, Storyn har Assets (text, bild, video etc) och tillhör listor)
– IT is better to be incomplete than inaccurate

Mål för NPR:s API:
1. Öka effektiviteten i utveckling
2. Distribuera till partners
3. Tillåt omvärlden at bygga tjänster
4. Öka flexibilitet i vad som kan göras med innehållet

Det spelar ingen roll vilket CMS som använts bara innehållet sparas på ett bra sätt. Abstrahera innehållet och spara inte som HTML är NPR:s tips. Här har vi en bra bit kvar…

(Infoga bild av NPR Architecture of COPE)

Hur har det gått senaste 3 åren? Resultat och lärdomar:
– Ökad effektivitet -> ja, endast utveckling i presentationslagret krävs i de flesta nya projekt
– När API:et är byggt måste det användas rätt (internt och externt)
– Skalbarhet är viktigt. Cacha, cacha, cacha.
– XML användes till en början hela vägen i API:et men det krävde mycket underhåll. NPR byggde om hela arkitekturen och byggde om till serialiserade PHP objekt. Enklare kod och mer rakt på. Resultat: bättre prestanda, snabbare utveckling, inga enorma DOM-träd.
– Bilder. NPR använder Imagemagic.

Vad händer om hela storyn bygger på Flash eller flera bilder för att fungera? Lösning: tagga upp det som är viktigt i storyn.

Viktigt att trycka ut uppdateringar och om artikeln blivit borttagen.

Har externa utvecklare byggt tjänster på API:et? Ja, t ex iPhone-app. En google-utvecklare byggde också en NPR-Android-app på sin 20% innovationstid.

Hur hantera t ex bokrecensioner i ett Storybaserat API? Det går men kräver mycket logik i presentationslagret. Det finns begränsningar och lösningen är att bygga ett recensions-API.

Tips: bygg inte själva utan använd Mashery eller liknande. Det fanns inte när NPR började bygga sitt API.

Frågor:
– Bygger alla tjänster på API:et? Ja, alla nya. Fortfarande finns legacy som inte gör det.
– Hur hanteras UX? Inom utvecklingsteamet i 2-veckorssprintar.
– Hur hanteras CSS för olika kanaler? Varje kanal hanteras separat. I det bästa av världar kan ett presentations-API fungera.
– Hur tar man sig ur ett CMS-beroende där innehåll och presentation sitter ihop? Lös det inkrementellt. Låt ingen lägga in html direkt. Parsa och städa upp lite i taget.

Mer info: npr.org/blogs/inside