Downloaded 19 times
![Artemis Library API
GET
/stories/?names={"or":[{"name":"Newt%20Gingrich","role":"4"},{"name":"Newt%20Gingrich","role":"1"}]}](https://image.slidesharecdn.com/imapbsandnprapifinal-120322165815-phpapp02/85/I-ve-Got-a-Key-to-Your-API-Now-What-Joint-PBS-and-NPR-API-Presentation-Give-at-IMA-Conference-March-2012-34-320.jpg)
![JSON APIs
XML JSON
<response> {
<status> response: {
<version>4.2</version> status: {
<code>0</code> version: '4.2',
<message>Success</message> code: 0,
</status> message: 'Success'
<songs> },
<song> songs: [
<artist_id>ARH6W4X1187B99274F</artist_id> {
<id>SOWKEUN12AF72AB837</id> artist_id: 'ARH6W4X1187B99274F',
<artist_name>Radiohead</artist_name> id: 'SOWKEUN12AF72AB837',
<title>Climbing Up The Walls</title> artist_name: 'Radiohead',
</song> title: 'Climbing Up The Walls'
<song> },
<artist_id>ARH6W4X1187B99274F</artist_id> {
<id>SOXZVWD1316771449E</id> artist_id: 'ARH6W4X1187B99274F',
<artist_name>Radiohead</artist_name> id: 'SOXZVWD1316771449E',
<title>Fake Plastic Trees</title> artist_name: 'Radiohead',
</song> title: 'Fake Plastic Trees'
<song> },
<artist_id>ARH6W4X1187B99274F</artist_id> {
<id>SOMLGKF12AB017DF3C</id> artist_id: 'ARH6W4X1187B99274F',
<artist_name>Radiohead</artist_name> id: 'SOMLGKF12AB017DF3C',
<title>Vegetable (Live)</title> artist_name: 'Radiohead',
</song> title: 'Vegetable (Live)'
</songs> }
</response> ]
}
}](https://image.slidesharecdn.com/imapbsandnprapifinal-120322165815-phpapp02/85/I-ve-Got-a-Key-to-Your-API-Now-What-Joint-PBS-and-NPR-API-Presentation-Give-at-IMA-Conference-March-2012-46-320.jpg)
Uploaded byPublic Broadcasting Service
I've Got a Key to Your API, Now What? (Joint PBS and NPR API Presentation Give at IMA Conference March 2012)
The document presents an overview of API usage and development, emphasizing the importance of flexible toolsets that enable content sharing and integration across platforms. It features insights from experienced professionals at PBS and NPR, discussing various APIs including content repositories, mobile applications, and television schedules. The session encourages collaboration and continuous improvement in API functionalities to enhance user experiences and streamline digital services.
More Related Content
Similar to I've Got a Key to Your API, Now What? (Joint PBS and NPR API Presentation Give at IMA Conference March 2012)
I've Got a Key to Your API, Now What? (Joint PBS and NPR API Presentation Give at IMA Conference March 2012)
- 1. I’ve got akey to your API, now what?!? •Presented by: •Thomas Crenshaw – PBS (@justhomas) •Javaun Moradi – NPR (@javaun)
- 2. Who are theseguys • Combined 30 years technical experience • Both straddle the line between technically focused and experience focused • Both work for 3 letter companies and won’t have to kill you for telling you that (inside the beltway joke) • Fun fact: both are mountain bikers
- 3.
- 4. Who are you?( Who who who who ) • Just Radio? • Just TV? • Joint licensee? • Digital folks? • Broadcast? • Developers (the software kind)?
- 5. Who we thinkyou are • Some development experience in some development language (python, ruby, javascript) • Desire to extend your site/app/presence with additional content • May or may not be a joint licensee • Know that APIs rule the 2.0 world • May or may not know that APIs are actually web services
- 6. Now that introductionsare out of the way let’s talk about APIs
- 7. We are goingto go through this part of the presentation “Vin Diesel” style....
- 8.
- 9. think of thisas API speed dating 10
- 10. Application Programming Interface(API) • A flexible toolset. Not a platform, a file format, or a type of content. • Reuse your own technology, or • Use someone else’s without building it yourself. • Skilled developers program new API applications, but everyone can use those new creations.
- 11. Where did NPRbegin?
- 12. Create Once, PublishEverywhere (COPE) • A central content repository that feeds all NPR platforms, stations, and partners NPR.org Mobile NPR API Story Pieces: headline, text, photos, audio, video Email Story Attributes: Newsletters Date, byline, topic, program, series, artist Partner Apps
- 13. Vision: “Let athousand flowers bloom…”
- 14. Reality: NPR +Stations + Partners
- 15. Rise of MobileApps PRX Brad Fluebacher’s basement NPR
- 16.
- 17.
- 18. APIs you didn’tknow we had • Transcripts ROBERT SIEGEL, HOST: From NPR News, this is ALL THINGS CONSIDERED. I'm Robert • User & Playlist Siegel. MELISSA BLOCK, HOST: And I'm Melissa Block. We're marking the 50th anniversary of a children's classic that's still devoured and puzzled over in reading nooks and classrooms. KEVIN THOMPSON: So we got Mrs. Whatsit, what about the 2nd character that we met? UNIDENTIFIED GROUP: Mrs. Who. THOMPSON: Mrs. Who, OK. What did we learn about Mrs. Who? UNIDENTIFIED CHILD #1: That her glasses are thick. THOMPSON: Yes, she has thick glasses. What kind of... UNIDENTIFIED CHILD #2: She has spectacles. THOMPSON: They call them spectacles, very good. What else is...
- 19.
- 20.
- 21. Station & ShowApps!
- 22.
- 23.
- 24. NPR Doubled PageViews NPR Music NPR Facebook Integration iPhone app iPad app Relaunched NPR mobile site API launched in 2008 Player 2.0 NPR News Android app NPR News NPR Music Homepage NPR Blogs iPhone app Remix Improvements Made API Friendly Story Page Improvements
- 25.
- 27. NPR API stuffin progress
- 28. Plugging Asset Gaps <externalAsset id="141487365" type="YouTube"> <url>http://www.youtube.com/watch?v=Ws6AAhTw7RA</url> <http://www.youtube.com/watch?v=Ws6AAhTw7RA%3C/url%3E> <oEmbed>http://www.youtube.com/oembed?url=http %3A//www.youtube.com/watch%3Fv%3DWs6AAhTw7RA </oEmbed> <externalId>Ws6AAhTw7RA</externalId> <credit/> <parameters/> <caption/> </externalAsset>
- 29. Station Ingest: 150 bythe end of 2012!
- 31. API-Centered Development • Rule1: Everything is an API • Rule 2: Be RESTful • Rule 3: Drink Your Own...
- 32. Streams & GenresAPIs GET: /genres/10003/streams/
- 33.
- 34.
- 36.
- 37. Station Data Project(BUS) • Schedule information • Bridge existing information, including: – Station localization – Streams directories • Lots of bad puns
- 38.
- 39. Update Our OldDocumentation
- 40. Better Documentation and Support
- 41. The API inthe beginning…
- 42. Ingest is gettingcomplicated
- 43.
- 44. An API forthe System • Independent of any one CMS or data structure • More flexibility • Versioning • Rights/permissions
- 45.
- 46. JSON APIs XML JSON <response> { <status> response: { <version>4.2</version> status: { <code>0</code> version: '4.2', <message>Success</message> code: 0, </status> message: 'Success' <songs> }, <song> songs: [ <artist_id>ARH6W4X1187B99274F</artist_id> { <id>SOWKEUN12AF72AB837</id> artist_id: 'ARH6W4X1187B99274F', <artist_name>Radiohead</artist_name> id: 'SOWKEUN12AF72AB837', <title>Climbing Up The Walls</title> artist_name: 'Radiohead', </song> title: 'Climbing Up The Walls' <song> }, <artist_id>ARH6W4X1187B99274F</artist_id> { <id>SOXZVWD1316771449E</id> artist_id: 'ARH6W4X1187B99274F', <artist_name>Radiohead</artist_name> id: 'SOXZVWD1316771449E', <title>Fake Plastic Trees</title> artist_name: 'Radiohead', </song> title: 'Fake Plastic Trees' <song> }, <artist_id>ARH6W4X1187B99274F</artist_id> { <id>SOMLGKF12AB017DF3C</id> artist_id: 'ARH6W4X1187B99274F', <artist_name>Radiohead</artist_name> id: 'SOMLGKF12AB017DF3C', <title>Vegetable (Live)</title> artist_name: 'Radiohead', </song> title: 'Vegetable (Live)' </songs> } </response> ] } }
- 47. Smaller, Simpler APIs GET /genres
- 48. CMS Convergence • Harder to go it alone • A few CMS/frameworks will dominate • Let’s share modules! Don’t reinvent the wheel • http://drupal.org/project/npr
- 49. Technology: Shiny newthings!
- 50. We need local,segmented audio!
- 51. An ecosystem forsharing
- 52. NPR is hiring! http://www.npr.org/about/careers/ DigitalMedia (Washington, D.C.) •Programmer III •News Apps Editor •Quality Assurance Engineer •Software Developer •Audio-Video Production Supervisor •Product Manager, Connected Cars •Lead User Experience Architect Digital Services (Boston) •Digital News Specialist •Project Coordinator •Programmer III •Web Application Developer IV •Client Services Manager •Client Services Associate
- 53. Hey what aboutPBS...we have APIs too...
- 54. TV Schedules I couldn’tresist the image of an Imperial Walker painted like the Mystery Machine! although it really doesn’t have much to do with the TVSS API! Very little knowledge passed down through the PBS Interactive group about the origins of the TVSS API (see “mystery” wrapping large cumbersome object....you get it now right?) 21
- 55. It works.... • Althoughnot without blemishes, it does work • Pass parameters into TVSS API • API returns TV schedule data back • Documentation greatly improved recently by WETA’s Jess Snyder • Built for single purpose, extended overtime to do handle other tasks that 22
- 56.
- 57. PBS Tune-in iOSApp 24
- 58. COVE API • Request video object • Get video object • Pretty simple at its core • Manual key management at PBS • Public key available for POC 58
- 59. WordPress Plugin WNET built itand is using it in production code is public on GitHub 59
- 60.
- 61. Other APIs 61
- 62. Image Transformation Service(ITS) On-the-fly image resizing using URL decorators http://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png http://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png.resize.103x58.png
- 63. Universal User Authentication (UUA) 63
- 64. Hey PBS ...what are you working on now?
- 65. Localization 65
- 66. Simplify the obvious Passedin parameters: ZIP, IP or Coordinates Return: Call sign Filter and rank as necessary with additional parameters 66
- 67. Document from thebeginning, not as an afterthought 67
- 68.
- 69. ~300 x 24x 21 x 3 x 4 = ~1.8 million records (Actually closer to 2.629492 million records in PBS TV Schedules grid of information but who’s counting) 44
- 70. Not the bestuser experience 70
- 71. assume the roleof a viewer 71
- 72. Build a robustAPI that fits the viewers needs and the user experiences will follow 72
- 73. Mashup COVE API +TVSSReloaded = EPG Nirvana 73
- 74. One ID torule them all 74
- 75. Ask the question wherecan I watch a PBS program? Yesterday 75
- 76. Today 76
- 77. Now that youknow what we are doing... what can we do for you while we are doing what we are doing? open discussion begins..... now 77
- 78. API Reference • NPR • PBS – NPR API – TV Schedules – Transcripts – COVE – User – ITS – Playlist – UUA – Stations – Localization – Streams & Genres – TVSS Rethunk – Artemis – PBSGUIDPROJECT 78
- 79. PBS URLs • http://open.pbs.org- open PBS • http://answers.open.pbs.org - Q&A site • https://github.com/pbs - PBS github site • http://to.pbs.org/docs-api-cove • http://to.pbs.org/docs-api-tvss • http://to.pbs.org/docs-api-its • http://to.pbs.org/docs-api-uua 79
- 80.
Editor's Notes
- #3 Tom 14 years development experience Lives and breaths core services such as APIs Product evangelism Little known fact: lived most of his 20s on a submarine Javaun Prior to NPR: Fortune 500 companies, dot-coms Developer, experimenter, tinkerer Watching/listening since the ‘ 70s: WTTW, WBEZ, WXXI, Michigan Radio, WABE, GPTV, WAMU, WETA, MPTV
- #4 Gnar! Dirt! Awesomeness!
- #10 at the end we will open discussion on any of the APIs but more importantly we want to discuss with you how we can help make your life easier through our API efforts
- #11 (CONSIDER GOING BACK TO JUST A FEW BULLETS ON THE NPR API, AND INSTEAD OF THIS SLIDE NAV TO SOME WEBSITES THAT USE GOOGLE MAPS API AS EXAMPLE) Who ’ s heard of the NPR api? Usually no one. What ’ s an API? No, we didn ’ t invent the term. Been around in software for over a decade. Nerdiest, sexiest thing that you ’ ve never heard about. API is not a platform. A radio, a TV, a pc, a phone are platforms. It ’ s a toolset. You build it because it allows you to create a lot of stuff over and over without reinventing the wheel each time. Also lets you use someone else ’ s tech w/o having to build or maintain. Simplest example is google maps. Who ’ s seen a real estate map w/ prices laid over geography? Show the Dr. Who map (good for a chuckle). This guy has the map on his blog. The embedded map is google ’ s, and he ’ s laid his data on top of it. Google developed maps at a huge cost ($$$$). They maintain it, improve it. When they shoot new satellite or streetview images, it automatically upgrades his Dr. Who map and he ’ s willfully ignorant of how it all works. Most APIs are tougher than this. It takes a programmer (less than 1% of the audience), but when those skilled people make good stuff, everyone can use it. So what is the NPR api? It ’ s a repository, a big bucket of all the digital content we have, easily accessible to anything that can connect to the internet. A pc, a phone, you name it. We ’ ve taken all of our content and sliced it up into pieces, so you can make requests by topic (give me environment, health, and business stories) by program (that appeared on ATC), by reporter (that are by Allison Aubry) by date, by series. Infinitely sliceable/diceable. Also, you can get whole stories are just the pieces. Give me text, photos, but not audio. Or just give me thumbnails and audio. Give me titles, links, and reporter names. The API is the big bucket of content at the center of all of our digital platforms. The website is one presentation of the API. An iPHone app is another. (will show a few more in the demos) Why is this good? We have the ultimate toolset. It means that everytime we want to put our content somewhere new, we never have to worry about how to get it there. We have everything in one place that everything can get to, and we can get it in whole or in pieces. (Sometimes I throw out examples, i.e. there ’ s a game called “ Grand Theft Auto ” where people steal cars. What if the game company came to us and said that when someone steals a car in the game, they want to be able to have the player turn on the dashboard radio and hear that day ’ s “ morning edition ” . We could do that tomorrow, the technology isn ’ t a problem because we already have this API that can put content anywhere that connects to the web – like an Xbox game console. So tech isn ’ t an issue, we ’ d ask “ is this an appropriate use of NPR content, is it the right opportunity, and how much will you pay us? ” Biggest user of the API is us. It let ’ s us create new stuff so quickly. In a way, the API makes us future proof. We don ’ t know what is coming next. We didn ’ t know we were going to make an iPhone app. Would ’ ve been so much harder and taken so much longer without the API. Second biggest user is our partners and our member stations who want better access to our stuff. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Here, I jump off to examples. Show “ Mix your own podcast ” . I make a podcast on the search term “ banjos ” . I explain that it ’ s calling to the API and saying “ get me all stories that have ‘ banjos ’ in them. But I just want to title of the story and the audio file, since that ’ s all I need for a podcast. I don ’ t need text or photos. ” In this way, my podcast is another presentation of the API. Everything is just another presentation. If there ’ s a reporter in the room, I make a podcast with their name (Howard Berkes, Karen Grigsby Bates) and ask them if it looks like the last few weeks of their life. Always a yes. I tell them to share it with their mom/stalker. If time, I may also show another use of the API, like the iGoogle Gadget. Depends on who is in the audience. Time to talk more iPHone…
- #13 Every where our content appears, it’s just another presentation of the same core stories. To make a web page, I need all the pieces at once. To make a podcast, I just need the story title and the audio link. An email newsletter needs title, teaser, and thumbnail photo, but not full text or audio. A mobile device needs all the pieces, but it calls them as it needs them. The first screen is just a news river with story titles and audio indicator icons. If you click through to a story, you see text and photos and can listen to audio.
- #14 We assumed that our audience would register and build things we never dreamed of.
- #15 The reality is that NPR, stations, and partners were almost all of the usage.
- #16 But the crowd did invent things. The first iPhone app was PRX. The second was written by Brad Bluebacher, a developer by day and NPR fan by night. This spawned the term “to be Fluebachered” in our department. It means that if throw disruptive tech out there and don’t act on it, someone will beat you to the punch. We reached out to Brad and gave him a thumbs up as we wrote our own app.
- #17 Our station app provides localization by city, state, zip, or lat/long.
- #21 A whole suite of new apps.
- #22 Stations are getting into the act too. Expect to see a lot more convergence using many data APIs
- #23 The cars app prompted us to rethink our APIs and add a few more for quality-checking streams.
- #24 And of course, the Infinite Player.
- #25 The interesting part about this graph is what’s not on it. We launched the API in summer 2008 but our usage (and resulting traffic) didn’t jump until a full year later when we launched the iPhone app. Disruption takes time.
- #29 This has been going on for almost a year. Asset gap analysis across all platforms. What goes where – and what doesn ’ t. Complicated and what appears to be a single issue (i.e. photos) may have many roots Photos – often rights issues. Getting AP solves a majority but not all of the issue Videos – Youtube is the biggest share. There are system & process reasons that other videos aren ’ t captured in our systems.
- #30 This is the most important slide in the deck. 150 stations by year end, ingesting into the NPR API. We’ll have the first news platform to cover world, national, and local news. This will be a great starting point for the Public Media Platform
- #31 Stations using stations’ content. This is crazy! The revolution is beginning!
- #35 Our library system’s search is run solely off the API, powered by Elastic Search
- #39 We’re about to begin quality checking our streams so that we can programmatically check formats and only deliver the streams that a device can actually play. We’ll also check to see if a stream is down and temporarily remove it to prevent serving a dead URL to our users.
- #41 We’re about a month away from launching our new documentation site.
- #42 . The API was originally centered around NPR systems because that ’ s the only way it could have ever existed.
- #43 We started by going through our mechanism, but you can see it looks complicated. The business reason has changed. We ’ re asking it to be something different, and that requires philosophical and architectural changes.
- #44 The API is the center of the system – everyone sends content in the same way (including NPR), and everyone pulls it out the same way. More flexibility to fit station data structures.
- #45 We ’ re asking our API to something beyond what was originally envsioned – the purpose is changing. A major refactor is underway. We ’ ve already rewritten Ingest from scratch. IT ’ s a very different API under the hood, and NPR Digital Services has done a lot of work to make audio ingest faster via core publisher. They now have the fastest station audio to CDN by a wide margin.
- #47 Who hear uses XML? JSON? Who loves XML? JSON? Proved my point
- #49 We ’ ll see a convergence of CMS. It ’ s getting harder and harder to go it alone. We ’ re building more APIs and constantly changing the ones we have. That means you not only have to upgrade your CMS, you also have to keep pace with API updates to ingest, retrieval. We ’ ll see a few key flavors of CMS. Not surprisingly, all of them are based on open source. We want something proven, but something that we know has a community dedicated to maintaining it. Drupal is a big one. NPR Digital Services ’ Core Publsher is a Drupal CMS. Other stations and some of the folks at MPR are using Drupal. WBUR and others, including StateImpact and ARgo are using WordPress OPB, WNYC, and others are using Django-based CMSs. Django is a framework that lends itself to reuse. There are full Django CMSs, including Armstrong (Knight) and Ellison). We need to share with each other. This is too hard and we should never reinvent the wheel. Doug Gaff told me there are some Open source Drupal modules in Beta.
- #50 We need to be open to new technologies that solve problems better and faster. We ’ ve used Elastic Search to great success on the Artemis Library project and giving us a powerful search engine in days, not weeks. You better believe we ’ ll keep experimenting.
- #51 We really need local, segmented audio. This was just an experiment, and we don ’ t know what it will look like as a grown-up product, but it will affect almost all of our platforms. We need segmented audio for mobile, for cars. I was really proud of this one, this was our first digital radio. An exec called it “ the most disruptive thing we ever created ” . We were like cool. Then holy crap. We did this in two weeks because we knew our APIs, systems, and the member station system. But someone else could ’ ve done it. Would ’ ve taken them longer. I ’ m glad we invented it. We have to remember what ’ s gone on with newspapers. Aggregators. They ’ re chasing everything. We have to own this, we have to control our destiny. Help us.
- #52 We all need to be willing to share more. More code, more content.
- #55 Not really sure when it launched Not really sure what the driving business need was other than drive the national PBS electronic program guide Not really sure if there were product requirements written up or if it was skunk works I am sure that I am in the process of rebuilding
- #56 Outages have been reduced The documentation has been improved Lived out its usefullness
- #57 WPT uses the TVSS API (or used to) but is able to punt on the channel/headend portion of EPG
- #58 Would not be possible without the API No native way to support the device
- #59 Migration path from application-centric web to API-centric web COVE 2.0 portal launched on COVE API Video portal driven by combination of COVE API and Merlin API
- #63 http://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png http://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png .resize.103x58.png
- #71 User enters ZIP code, chooses headend (provider) which may or may not be familiar to them depending on location and finally gets what’s on a particular station Flawed user experience that puts station first and user second
- #72 TV viewer really only cares about “What is on that I can watch” or “when is the next showing of my show on air” Overlap markets can play nicely together
- #74 double usage out of the imperial walker painted like mystery machine image By combing the COVE API with the updated TVSS API, we will be able to host previews and other interesting user experiences within the EPG
- #75 Multiple IDs on the internet that index and describe single entities whether they are programs or episodes Creating a single PBS ID and leveraging the power of the cloud, we can create a single ID that we can provide to the other content providers, both local and national
- #76 Remember when there was 1 way to watch a program and you had between 4-8 channels to choose from?
- #77 Connected TVs, programming on the web, station and national portals, iTunes, Hulu, Netflix are all providers of PBS content. Not just broadcast and EPGs
- #78 Let us know how we can help you. What are we doing right? What are we doing wrong?