Inside NPR.org

API

Suggestions for the Next Version of NPR's API?

It has been almost a month since we launched our API and we are now preparing requirements for our second release. What would you most like to see in the next version? Are there specific fields or standard formats that you would like us to output? Are there topics or other ways of slicing the data that you would like represented?

Comments

 

Please keep your community civil. All comments must follow the NPR.org Community rules and terms of use, and will be moderated prior to posting. NPR reserves the right to use the comments we receive, in whole or in part, and to use the commenter's name and location, in any medium. See also the Terms of Use, Privacy Policy and Community FAQ.

Wow! I'm just scratching the surface with what can be done right now. Do you all take a day off? If not, you deserve it! But since you asked, my next priority would be including longitude and latitude information with every record.

Sent by John Tynan | 2:02 PM | 8-11-2008

what is an API?

Sent by lance | 7:35 PM | 8-11-2008

I would like to see a way to slice the data by country / state / region

Sent by John Tynan | 7:09 PM | 8-12-2008

Lance,
An API, which stands for Application Programming Interface, is basically a way for different computers or applications to talk to each other using a common language. NPR's API is a way to allow other web sites or applications to get access to NPR content using our documented ways of accessing it. To see that documentation, go to the NPR Tech Center.

To read more about what an API is, you can go to Wikipedia's definition of API.

Sent by Daniel Jacobson | 7:36 PM | 8-12-2008

be great to have the ability to select among Audio stream choices, ie, Real, Win, MP3, instead of current config which allows all or nada. (i'd choose to display mp3-m3u only, btw, for our site.)

Sent by Barrett Golding | 11:21 AM | 8-13-2008

be great to have the ability to select among Audio stream choices, ie, Real, Win, MP3, instead of current config which allows all or nada. (i'd choose to display mp3-m3u only, btw, for our site.)

Sent by Barrett Golding | 11:45 AM | 8-13-2008

Barrett,
You can show mp3 links only on API output by suppressing the links to the Real and Win versions via your site CSS. For example:
}
.nprModLinkReal {
display:none;
}
.nprModListenIconReal {
display:none;

You can get all the appropriate class names from the API documentation or by looking at the generated source code of an API query output as html. You can see a sample of NPR API output with mp3 only links at this address:
http://www.northcountrypublicradio.org/news.php

Sent by Dale Hobson | 4:23 PM | 8-13-2008

I've occasionally heard programs refered to by their acronyms: ATC, ME, ASC, TOTN, etc. These could be used as group tags in twitter (as well as other programs to aggregate comments)... of course these would need to be promoted, to be part of listeners vocabulary to be useful. If these standard abbreviations were included as a property of items listed in the programs feed: http://api.npr.org/list?id=3004 perhaps these could be used by apps (like All Tweets Considered) to not only search by title, but by group tags like #TOTN as well? Sound useful / Interesting?

Sent by John Tynan | 1:38 AM | 8-14-2008

thanks, Dale. very slick. guess i didn't rtfm, as they (used to) say; 'least not the css part, assuming there is a published set of css selectors -- or perhaps you found the above classes by inspecting the html output. in either case, thanks muchly.

Sent by Barrett Golding | 10:02 AM | 8-14-2008

Hi John,

All Tweets is already looking for all the standard abbreviations. So when you search for Talk of the Nation, for example, TOTN will be picked up in the search results.

Sent by andy carvin, npr | 10:21 AM | 8-14-2008

Thanks Andy, would it be appropriate to include these abbreviations as properties of each show/item as part of the xml for the programs feed? This way, these terms could be programmatically be incorporated in scripts, without having to hand code them into your scripts.

Sent by John Tynan | 10:49 AM | 8-14-2008

Dale and Barrett,
The documentation currently does not have the CSS information for the HTML and JS widgets, but thanks for pointing this out to us. We will include it in the next release of the documentation. In the meantime, the CSS classes are the same for the HTML and the JS widget and everything is suppressable in the way that Dale describes (once you know the class names). Here is a list of classes:

nprModStory1 (the number increments for each story)
nprModHead
nprModText
nprModDate
nprModPipe
nprModName
nprModAudioLinks
nprModLinkReal
nprModLinkWindows
nprModLinkMP3
nprModLinkPlayNow
nprModLinkAddToPlaylist
nprModAudioPipe

The documentation will contain more details around these classes, but hopefully this will get you started.

Sent by Daniel Jacobson | 11:17 AM | 8-14-2008

http://www.npr.org/blogs/inside/2008/07/npr_api_is_live_on_nprorg.html

John L.,
Your question about the technology decisions is a good one and we will be posting some more details about this (in a separate blog post) soon.

Sent by Daniel Jacobson | 2:23 PM ET | 07-17-2008

How about the technology decisions you made in development? If we know how you went about making it, that might help us to suggest future additions.

Sent by John L. | 1:23 PM | 8-14-2008

John L.,
We haven't forgotten about this request. We are in the process of going through our notes and will be posting more of those details shortly.

Sent by Daniel Jacobson | 8:40 PM | 8-14-2008

All,
Thanks for the suggestions and we welcome any more that you have to offer. We will be compiling these and other ideas and will be putting together the requirements for the next release soon. I will post more to this blog when I have more information.
Thanks again.

Sent by Daniel Jacobson | 9:28 AM | 8-19-2008

I suggest you add support for Fire Eagle and let us NPR listeners/readers connect with one another if we want to. You could also tie the Fire Eagle API into your RSS and Twitter to provide a sense of place to the content.

Example, if a breaking news story is occurring near me, a text message arrives on my phone. I may be able to stop by the event or news and then call you and describe what is going on, live, via the phone.

Just an idea. Fire Eagle is here:

fireeagle.com

Sent by Todd | 12:28 PM | 8-19-2008

If I type in a search term like "michelle obama" how can I ensure that the stories I get back are about Michelle and not about her husband? I know you have boolean operators for IDs but, do you have a search syntax like the one used by Google, for instance: http://www.google.com/help/cheatsheet.html Thanks,
John T.

Sent by John Tynan | 9:57 AM | 8-25-2008

would it be appropriate to include these abbreviations as properties of each show/item as part of the xml for the programs feed?

The program codes are available in the feeds. If a story belongs to a show, you can go to the story->show->program node and get the code attribute

Sent by Harold Neal | 1:30 PM | 8-26-2008

John T, regarding getting back the search results you want, I have a couple suggestions. First, set searchType=mainText in the query string (in the query generator this is the "Summary of Story" option in the search type drop-down of the Control tab). This will cause the search to only look at titles and teasers of stories. This will filter out stories where the search term might have been mentioned in passing during a story about something else. Second, if you are searching on multiple words, put them in quotes in the query generator. The quotes must be escaped when the query string is written, so it will look like searchTerm=%22michelle%20obama%22. This will only find occurrences of the exact phrase you specify.

Sent by Harold Neal | 1:42 PM | 8-26-2008

Inside NPR.org
Support comes from: