Tip:
Highlight text to annotate it
X
Event ID: 2053121
Event Started: 11/27/2012 4:00:00 PM ----------
Please stand by for realtime captions. >> Good morning, everyone. We will be starting
the webinar shortly. If you are having technical difficulties, call GoTo Webinars at 1-800-263-6300
and selection 2, then option 1 and option 1.Again, we will be starting shortly. Thanks.
>> Good morning, everyone. Welcome. This is Greg Brooks from GSA.We are joined by Nick,
from the national renewable energy and will be introducing more about him in a moment.
I want to provide a little bit of background on why we are having this webinar, and also
some of what we are going to be covering today. And going forward from here. A number of you
have dialed into previous work. Have had in the past several months. We began with some
introductory, what is a API, but also providing more case studies and more coverage of some
technical questions that have come up and strategic questions that come up when doing
APIs in government. >> Just to basically inshore to cover it,
because we always know that there are new people dialing each time. Actually, there
are several ways of defining an API or application programming interface. Basically, it is a
technology that allows machines to machines communication. You can allow computers, websites,
applications, devices to communicate automatically without having to have human intervention.
The way I look at it is, for instance, it is what mobile apps are built off of. Pretty
much anytime you see a third-party developer build an app off of something, whether it
is weather data or flight information or anything else, they are oftentimes consuming an API
. >> But really, we are going much more deep
and providing resources so that your agency can actually start wherever it's at, the beginning
or well a long, and make forward progress using Web services as part of their work.
And all of this was kicked off by the launch of the digital government strategy back in
May, six months ago. >> So, for today, I'm going to be talking
some about the digital strategy itself, what it says, and then a large amount of materials
that are going live at the moment, to provide resources for agencies. This will actually
be the first time that we are sharing this now, so I definitely want to get your feedback
on it as well because we're going to continue to reiterate these resources and make improvements.
>> The feedback that you get today and going forward from here, you know, we will turn
around and act upon it. We are also joined, again, by Nick, because the national renewable
energy laboratory is an interesting example of one of the agencies that is really doing
APIs well, and in a fleshed out, well-rounded way. You have heard from some other agencies
who are also in that class, but as we go through this stuff, I think that you will see the
actually, it is about assembling a number of different components together. And I think
that the example of Nick's team is really helpful here.
>> So, just a few notes. This is being recorded and will be available after the fact. If you
have to break off or if somebody that you work with you think might benefit from this,
it will be posted after the fact that howto.gov/training. And then, also, later on in the event, we
will have a Q&A session. So please, you can send in your questions during the webinar
and we will keep a list of them. Or, send them in during the Q&A session and we would
definitely to address anything on your mind or that you would like to learn more about.
>> Lastly, all of this is part of the digital services innovation center that has been launched
by GSA to support the implementation of this digital strategy. And, you know, it fundamentally
serves a number of roles that we are going to get into with this. But, we also want to
encourage you to get in touch with us, and start to partner with us and make the work
that GSA is doing more productive and more successful.
>> So, to that end, just a brief bit of overview. So if you recall, the digital strategy launched
back in May of this year. It sets out a number of milestones and items. And one of those
was to actually launch a digital services innovation center at GSA. And, you know, you
actually see its goal right here was to support agencies. And all of the requirements of the
general strategy, as well as just other for thinking changes and technology shifts going
on. >> You know, this needs to be something that
is very pragmatic. Where OMB was articulating a number of milestones and, you know, projects
that agencies needed to take on, but then, GSA's role was to provide support for each
agency, no matter where they are at. Both at a broad level, and also we want to work
with you personally, as well. >> To that end, we just recently went live
with howto.gov/api. So, this section will actually be continuing to grow and be flushed
out. But, it is a start. >> And to that end, we want you to have some
of the resources that are brought to bear here, but also, we want to really get your
thoughts and input on how it could be better. You can see in the right sidebar here there
are a number of different sections. And each one of those sections actually has at the
bottom a commenting section, so that I can encourage people today and any day going forward
to provide comments, requests, new content, suggest changes to content. If we have missed
something, please let us know. And to that end, we will continue to iterate this and
have it be a resource that you cannot just use your self, but tends to other people within
your agency to help them, whether they are just getting started or growing forward from
here. >> It is worth focusing on, for the digital
strategy at least, what the goals are for May of 2013. We are currently in the six-month
mark. If you actually look at the digital strategy, you can see that there are one,
three, six and 12 month time frames. When you go down to the appendix at the bottom
that lays them all out, you will see that many of them are built to lead up to six-month
marks, and then have agencies consuming [ Indiscernible ].
>> One was apartment 3.5, provide support and help agencies develop APIs. And to that
end, we know that there needs to be put resources, as well as information. Because every agency
has different needs. This is combined with the actual API centric requirements and strategies.
For those who have seen this, I don't mean to 12. But it's really important, if you have
not seen this, to see why we are having this conversation and why this is on the plate.
>> So, OMB is on track to issue governmentwide Web API policy and identify standards and
best practices for improved interoperability. This should be coming out in the near future.
And when it does, by the way, we will be updating a lot of content on howto.gov to directly
respond to that and provide suggestions and useful tools to consume those.
>> And then agencies are on track to ensure that they start to consume this policy, and
in other words, start to produce APIs. The specific requirement for 2.2 is to make at
least high-value data or content available through web APIs by May.
>> Each agency has a point of contact with OMB to be dealing with this. If you don't
have your contacts, get in touch and we can ensure that you get in touch with that contact.
The point, though, is to make sure, some agencies will already be completing this requirement
in passing. But many others will not. And the reason to try to have these milestones
is fundamentally to make sure of one thing. >> Every government agency has some sort of
public constituency. And, some sort of content that it deems important to provide to the
public, and services that it deems important in the business that it runs with the public.
If you look at your web presence, we know that it is built off of those two things.
Information that is important to make it successful, and services that are important to provide.
Or, interactions. >> By thinking of those and taking a step
back and looking at how it is today, we understand that the way the world is going, you know,
supporting third-party reuse and spreading those content services out is really core.
So, take a look at the example of the National Weather Service. And they did not set out
and say, we are going to make a smart phone app for weather, they have been putting the
data out in such a way that doesn't -- dozens of other people are able to meet -- make weather
apps for smartphone did appear >> Believing that has a lot of application
here. When you start to think along those lines for all of the interactions and different
constituents that you have, you know, they come into play. The goal is to get people,
and get agencies to start doing that with their content and services by May of this
coming year. >> There is also a reference to operationalizing
agency.gov/developer pages. And we have some material on that as well, and we are going
to be growing that out for. But basically, there needs to be a hub so that developers
can come to a new agency, they can come to your agency for the first time, and whatever
APIs you have made available, they should be able to find them and interact with them
in a way that, you know, is convenient and usable.
>> Because the more that these partners start to get our content out and give them to people
more effectively, that better serves our constituents and people. And they are able to get government
information and services they need just, you know, wherever is most convenient for them.
>> So basically, that is getting started with APIs and assembling a hub of those APIs , are
pretty much the fundamental goals for me. And also along the way, have agencies as a
whole become more familiar with this concept. A lot of the material we are going to go through
now actually is meant to be a resource for you, be a resource for other people that you
can send them to help acculturate them. >> What we have found is that the role of
APIs is not a fad, it is actually very much the way that significant portions of the Internet
are doing business now. You go to Google, you go to Bing, Amazon, eBay, Twitter, Facebook,
all of these websites are actually, through and through, running APIs at this point and
using them as part of the strategy. We think there is a strong lesson to be learned.
>> We want to take a minute now and go through the material that is now live on howto.gov
. Again, the URL is howto.gov/api. It is going to continue growing that this is what we have
to offer right now. >> Most fundamentally is, what are APIs. We
know that is a very tricky question, and honestly, just reading this and starting to wrap your
head around examples and some of the benefits that fit in there, I think, is the right place
to start, if that is the right place for you. >> Also, again, part of this is about getting
the right resources in front of your coworkers, superiors, etc., so that they can understand
this and work with you on these projects. You know, one of the biggest things people
have to think about is factoring in the benefits of APIs. And I really can't you from experience,
over at the federal communications experience and in talking with other agencies, the communications
are just as much internally as they are for the public as well.
>> And I think getting the content and services that we provide to the public, making those
more widely available is unimportant and unto its own. Before we found is that when you
start to build Web services, build APIs, and then consume those for your projects, there
is significant time savings, significant cost savings, and you are able to develop products
marked the. There is a lot of virtue and directions, and you can learn more about that in here,
but honestly, sometimes, the best way to realize that is also to just start prototyping. Start,
you know, trying out. >> So, from the same mind, we also know that
for agencies who are maybe just getting started, just happy your head around some of the basics
are really important, too. There are a number of the goal choices that come up, if you want
to get into that here. But on a more fundamental level, again, I would say that some people
choose to go with XML, some people choose to go with [ Indiscernible ]. There are different
ways to format and choose protocols and make these difficult technical choices.
>> At the end of the day, it is more about getting started, working with stakeholders
and developers to prototype something, measure it, and then keep going. And kind of that
wash, rinse, repeat mindset is how agencies become fluent and capable in this sector.
>> Another thing you're going to do is recognize that agencies are going to have to start thinking
really about APIs as not all that is similar to the web presence before. You have a public
web presence or a private web presence. You have a president that overlaps between public
and private. And there is security and technical aspects to maintain that.
>> But really, it is kind of a similar dynamic that have always dealt with in the past. And
it is not anything to get caught up on. There is some more material in here on how to start
the API program. We tried to provide bullet points but extrapolate into much more thorough
coverage. And lastly, there is a resources and tools section, and an FAQ section.
>> Within that, you will see on the right sidebar, in addition to earlier webinars,
there is also an index. And so, just briefly going through those, and actually, I would
like to wrap up pretty soon and focus on the example of Interel, because that is very telling.
>> There is the issue of, all of this needs to be practical and you need to think through
what benefits APIs can bring to your agency, and how to factor those in when you are, you
know, working with stakeholders who do not perhaps understand APIs as well.
>> You know, when I tell people about getting started with APIs, one of the things that
I say, and it is true, the third API is easier than the second, the fourth is easier than
the third. But the best place to start, and we get into this here, is really to start
to see if your agency has any APIs already, if there is a developer hub, because you want
to think about any new APIs within the context of what you have already produced.
>> One of the things, which actually people don't commonly miss, but, you know, you may
have APIs and your agency already and not even know it. If you look at some of the targeted
site-specific ***, there are ways to use a search engine. I used Google here as an
example. This can be very useful. So, I just searched the term API, and then GSA.gov. And,
what this does is it returns the word API across GSA's websites.
>> And so, by going through these different results, I can actually find a few different
places where APIs are mentioned. And that will often times we need to finding something
I did not even know was at my agency. >> Another example is, you could do JSON at
my website, and that is a good way to find certain things. One other trick is, if you
have say, three or four different domains that you are taking into account, so, if you
notice here, what I am actually using is an "or" operator which will search for the word
JSON across each of these domains. What that does is, across each of these domains, I can
basically find examples or places where there might be APIs that I did not even know about,
as you can see right here. >> So those are meant to help you audit what
is already there. And then, you actually want to go through some of the thought processes
of how to choose early candidates for API production. You know, it is basically averaging,
for you, what makes the most sense but either what is your most popular or important content,
but then, also, what could he get started with easily? We really encourage prototyping
early to get started. >> You know, you can go with a soft launch,
you can basically just get your feet wet. And once you have come through this process,
it is a very useful exercise for your team. And I think it will be helpful for all of
them to see these steps in action as well. >> Some of the other things, just to wrap
up kind of what is in this section, you know, there is an overview of how to make APIs.
I really want to disclaim that it is very difficult to be fully comprehensive. And so,
please read this and think about how it applies to your agency, but also recognize that, you
know, each agency's past is going to the individual. >> What we have found is that different agencies
sometimes will just convert some material into XML or JSON and host that live.There
are actually free and easy ways to do that, we link to some examples, and we encourage
you to give that a try. By providing important data that you have in JSON, instead of or
in addition to, you know, spreadsheet formats, in addition to is better, that makes it just
all the easier for third parties to start to build with them.
>> But then, you will start to see there is a number of new tools and resources that can
automatically build APIs around a spreadsheet that you upload. energystar.gov Has some really
impressive materials where they launched a section that they are able to upload a CFC,
and then gives back a very mature advanced, you know, API documentation.
>> The other steps to highlight is a lot of databases, you know, My SQL, Oracle, a lot
of these have APIs built in. If you work with the system owner, you can have an API faster
than you think. Building it into the system requirements. Lastly, there are a number of
examples. We saw this in an earlier webinars with the department of labor, where it is
about building a team that collectively builds and maintains the APIs of the agency.
>> Some other things to see and there, they're going to be in the resources and tools. This
will continue to grow out quite a bit. We wanted to highlight examples for some perspective.
There is a webinar series that has been going on here. There are a number of case studies
from CDC, the department of labor, Federal Register, here at GSA, health finder.gov,
the FCC national broadband map, and the national renewable energy laboratory. We think those
would be very helpful. >> There is an API release kid that gets into
a lot of components that are worth including. And then, I really, really want to stress
that where ever you are at, wherever your agency is that, you know, we tried to put
in front of you some recommended reading that I think you will find really worthwhile. And
each of these websites often times has other content that would be very relevant. API evangelist.com,
programmable web.com, both of those are significant resources that have the answers. Like, we
in government often times make the mistake of feeling like we need to rebuild things
from scratch, when the private sector actually has figured this out a lot.
>> If you ask me to tell you what the top 10 worst API mistakes are, instead of me trying
to think through that and give that question, I really want to just actually points to this
piece on programmable web. You know, when people ask what the common building blocks
of APIs are, I really do .2 API evangelist because they have been doing this very well.
The recommended resources in the tools section, please check out.
>> We are working on some content, some actual software to open source, and keep an eye on
GitHub.Proof some great help on GitHub, and you can see that link on recommended reading.
To that end, I have been talking too much, I'm sure, but I wanted to provide an overview
of what was available within this. And like I said, please use the content section, use
the feedback, and tell us more of what you would like in here.
>> Now, I want to take a minute and handed over to Nick. And Nick, if you would begin
to really kind of correlate to your agency and how it has played a role.
>> Yeah, thanks, Greg.I am Nick Muerdter, and I work at the national renewable energy
Lab, it is a Department of Energy laboratory focus is all on renewable energy. Anything
from solar, wind, biofuels, all of that sort of renewable stuff. Delete of the research
on that, and then where we come more into the picture is sort of then disseminating
that information to the public. Or, to other researchers.
>> So, I have been heading up the development of some of the APIs here at Interel, so I
guess I will sort of give you a brief introduction of how we got started. So basically, you know,
people have been wanting our data for years. And we have been sharing our data for years,
but sort of, the older ways of sharing data, by spreading spreadsheets, or sending people
dump of powerful database of them. But all of these mechanisms sort of have their problems
and their difficult to maintain. >> You know, it was a burden for us to deal
with, and there was also sort of growing demand for more immediate data from our customers
and clients. You know, people want to live feeds of our data, rather than month-old downloads
that they had to maintain and ensure that they had up to sync with our latest data.
That was really the driver for our APIs. This sort of demand from the public and customers
that we deal with to have access, more immediate access, to our data through APIs .
>> That has been really helpful in getting us off the ground. There was this demand there.
And even if you are not getting asked, there is probably demand for your data. The government
has a lot of data that other people don't have. So, you know, by putting it out there,
publicly accessible, easily accessible for other developers, I think you will be amazed
at what people will start to do with your data, and how they can utilize it to build
apps and build new things using your data. >> So basically, you know, I think a few years
ago, we started this API endeavor. And a year ago, we launched developer.NREL.gov, which
was the hub for all of the APIs at NREL.We identified early on that we had a large organization
and had different groups that were already wanting to build APIs, but we were not really
working together or standardizing, they were in difficult places. You might not even know
that somebody in your agency already has APIs. If you point out ways to find those.
>> We wanted to centralize that effort. Because it is a big benefit for the end users. It
is a big benefit for the end-users to be able to find all of your kind seven in one place.
To be able to go to one place and find all of your APIs without having to resort to searching
on Google for certain API things on your domain. Started an effort to build this hub.
>> You will see the documentation for various Web services so that, you know, buildings,
we do stuff with climate data, electricity data, utility rates, solar stuff, transportation.
Currently, we have about 13 APIs launched. Different groups at NREL are responsible for
a lot of these different topics. So, we wanted the essential thing, so, you know, an end-user
could go to a single place, sign up for an API ID and use any of the APIs easily.
>> As an example, I will dive into some of the transportation stuff. Alternative fuel
stations. This was our initial driver for a lot of the APIs. We have been sharing this
data for a few years, but there was demand from app developers and industries to get
easier access to this data in APIs. Google was interested in this data, MapQuest was
interested in this data, car manufacturers were interested in this data. Satellite navigation
providers were interested in this data. By putting it out there as an API, we see a lot
of nice benefits in terms of adoption. And ease of adoption for those end-users.
>> So going through some of those basics that was outlined on that side, there were a lot
of choices to make when designing your APIs. To start out with, there was sort of the protocol.
How do you decide? I would say for the most part, throughout NREL, we are using rest . And,
I mean, there are pros and cons to everything. But I feel it from our perspective as developers
to consume other people's APIs, we often times prefer dealing with rest APIs. They tend to
be easier to get started with. So, that is what we are using across the board. That is
what we are using here at NREL In terms of format, we have mostly standardized at providing
both JSON and XML. >> We typically use frameworks that make this
kind of providing both formats easy. So, we use a lot of Ruby on rails, we use some Java
stuff on the back and, the services are written in a variety of languages. Typically, if you
are using some sort of web framework, it is pretty easy to provide both JSON and XML.Here
is an example of downloading all of the alternative fuel stations data, and you can get either
JSON or XML output. But, they tend to be pretty similar.
>> I would say based on our statistics, we see a lot more use of our JSON stuff, so for
what it is worth, that is where we see more of our use. But we do see some use of XML.
>> We also provide a lot of data in CSV format, for those people who are used to spreadsheets.
A lot of this stems from our historical usage for people wanting to download data as a spreadsheet.
>> Another big thing that we decided up front, and it was important, was sort of authentication.
And, this is a big thing, and this sort of gets into more API management. It is one thing
just to put your APIs out there. But, there are a lot of other pieces in API management,
in terms of actually publishing your APIs in a way that is scalable and successful,
and easy to maintain. >> Basically, we wanted some sort of authentication
mechanism. So we just had a general sense of who's using our APIs. You certainly don't
need to do this. You could have fully, wide open APIs that is purposefully valid. There
are lots of different ways to handle authentication. We want a very simple API key system. You
sign up for an API key, you provide some details such as name, e-mail address, and a website.
I would probably caution against requiring a website, because I think that is definitely
a shift that we have seen in the past few years that as more and more app developers
come out, they don't have a website, because you know, their website is just iTunes, the
store. >> I think if you could select name and e-mail
address, and also act for -- ask for an option, how are you going to use APIs, they may or
may not tell us. We also have terms and conditions. This is an important thing. Part of our process
in launching this publicly was getting sort of a standardized terms and conditions that
apply to all of our APIs across the board, because we did not want to have situations
where some of our APIs uncertain terms of conditions, and certain other ones had different
ones. It is just a confusing mess for end-users. >> That is not to say, certain APIs, there
might be a need for that eventually. Most of our APIs are generally, publicly broad
data, so we were able to get away with a very broad license that sort of grants liberal
usage. Once you sign up for an API key, you get this API key, it tells you what it is.
Basically, it is just a big string. And immediately, you can start using that to access all of
our APIs. >> This key will work with both our transportation
APIs, solar APIs, climate APIs and all of that stuff. Here is a quick example right
here. Here is one that does a nearest search on our fuel stations data, relative to our
location here in Colorado. I could click on that, I him using my custom API key, and I
get that data. So, API keys are a simple way to at least start tracking usage, because
then we can actually tap into this API key and start performing analytics based on that.
>> We can see where our usage is coming from, and, you know, how much each individual service
is being used and by whom. So, that funnels into our analytics system which is another
big part of what we wanted to do as part of an API management platform . We wanted all
of our APIs here at NREL to be able to have analytics easily accessible for all of them.
So, you know, any service on our developer network, we could easily gather analytics
and usage. And that API key also is used for rate limiting, which is another important
part of our API management. >> And so, rate limiting is just basically
ensuring that one user is not just hammering your server away, and, you know, just obliterating
it and your and server cannot actually handle that kind of load. By default, I think we
have rate limits of a single API key can only make 1000 requests per hour and 10,000 per
day. All of that is easily set, we just arbitrarily set the servers so that they don't get hose.
And we can work with client who need higher rate limits for some reason. But we set up
the same default women to prevent attacks on our servers.
>> So you know, there is a lot of different options as far as, you know, these go. And
I think that the new site, with the howto.gov is a great example of outlining those options
per protocols, formats, how to perform authentication, and a lot of these options, where you need
to make decisions, for your APIs . And you don't necessarily need to do this up front,
but we sort of decided before we publicly launched the APIs, we wanted to tackle that
upfront to get everything on the same page before we launched.
>> We have one cohesive offering to the public now. Behind the scenes, as I mentioned, a
lot of these services are managed by different groups within NREL. But, the end user does
not need to know that. All they need to know is there is one site to find all of our APIs
here at NREL. >> It makes it easier for users to find APIs,
but it also makes it easier for us developers. The way we designed our platform is such that
anybody at NREL, the people at NREL building new services don't need to deal with stuff
like authentication. That is handled by our platform. They don't need to deal with rate
limiting. That's handled by our platform. Building this platform has also made it a
lot easier for us to build new Web services without having to worry about those, and details.
>> As far as what we have seen from this, you know, I think we have launched 13 public
APIs , 366 users have signed up, over the past year, we have had a little over 800,000
API request made by the public. >> But, we have also had 29 million internal
API request made. As was mentioned, I highly recommend building APIs and using them and
consuming them internally. I think there are a lot of advantages to designing your system
that way. And by using your own APIs, I think you will also see, you know, what might be
missing. For example, we had our alternative fuel station that we have launched a few years
ago, but recently we designed one of our tools, our station locator, to use that API.
>> In the process of doing that, this tool only uses our public APIs. And we found a
few omissions that we need to add to our public APIs which has benefited everybody. So, we
use our APIs a lot integrally. As a result of that, we have also seen probably a dozen
iPhone, Android and desktop applications using our and seven. It is helpful to see that other
developers are using our data in a new and interesting way, or just building an iPhone
app to expose our data in their own iPhone app.
>> So, as far as what is next -- oh, I guess I have rambled a little bit too long. I'm
running out of time. We have about 40 more APIs in the pipeline. We are also sort of
working to add more things to our overall platform, new features. The way this has been
designed, adding new features to our platform benefits everybody in terms of other developers
at NREL and making it easier for them to develop new APIs .
>> We also were involved earlier this year in setting up a prototype at api.data.gov.
This is a very preliminary prototype. But the concept is the same. A lot of this stuff
can be handled for you, in terms of signing up for API keys, rate limiting, authentication,
all of that sort of stuff. We have been involved in sort of taking our platform and applying
it in sort of a broader sense across agencies. >> So, this is a very early prototype, but
something that is coming down the pipeline. The basic goal is that we really want to aggregate
all of the APIs in one place . Purely just so that we can list the APIs, and list easy
ways to access all of the documentation. And that makes it easier for end-users to find
APIs and access all of those APIs. That is a little something coming down the line. And
I have sort of glossed over that. >> We have also open sourced our whole open
management system. A lot of the stuff I talked about about rate limiting, authentication,
documentation management, a lot of that that we have standardized has open sourced in the
API umbrella platform. I will not get into it because I'm definitely over time. But it
is all open sourced on GitHub. So, I am sure that I have missed several things and sorry
for going a little bit over but I will pass it back over.
>> That actually works very well because we are starting to get some questions that tie
in directly with this. So, to the point you were just asking, one person said, they asked
about 10 min. ago, do you have a custom code for the rate limiting, etc., or do they come
in a packaged software? Do you mind giving a little bit more background on API Umbrella?
>> We started tran5 Umbrella, probably about three years ago, but we did not publicly launch
it until last year, and then we just open sourced it probably a few months ago. So,
it has sort of been in the works for a wild. This is a whole open source platform that
deals with all of that. That being said, within just the past year, we have seen a lot of
these similar tools, online. And there are a few other open-source alternatives, a few
commercial solutions to do this, the same sort of API management stuff. I recommend
you checking all of that out. Commercial solutions, other open-source coalitions -- because I
think this is an important part of launching APIs.
>> Our stuff is open-source and we are continuing to work at it but there are upstart -- other
options out there. >> One of the things, and actually if I could
get the screen for just a second, let's see, one of the things that I would recommend and
reading into more is this concept of API management systems. One of the great things about government
open-source is it is being created by agencies, just like yours, and there is no reason why
you cannot go ahead and start, you know, experimenting with that already.
>> If you go to GSA's GitHub account at GitHub.com/GSA, one of the things he will see his federal
open-source policies. It is a hub that we have made so that you can skim through basically
all of the open-source projects across different GitHub accounts. As you can see, there is
quite a bit and it is growing, and I think that's outstanding. If you get down to NREL,
you can see a number of the projects rolling out. So please do, and take that prototype
back. >> But one of the websites I was mentioning
earlier, apievangelist.com has a section called service providers. And it is worth starting
to get familiar with this sector, because a lot of them are providing solutions to an
interface where you type in and basically just stand up for API to begin with, and depending
upon what service it is, it may provide analytics, rate limiting, you know, documentations sometimes.
Basically, a whole lot of these important aspects.
>> I know that several of them will be adding a list on the API, but several of these have
premium model so that you can get started at no cost and prototype in really get a feel
for this. But also, if you actually go to -- one of the sections within howto.gov/api
includes the components that sometimes go along with APIs, and examples that you can
look at. But also, other, basically, potential resources as well. For API key management,
you can see API.data.gov, and if your agency is interested in that, please reach out.
>> But also, there are some open source projects as well. But from a private sector, they also
provide solutions for API management. And I really recommend every agency thinking about
this, prototyping with this, etc. One thing I want to make sure to reiterate, two, is
just looking at what other agencies have done and imitating it. You know, the terms of service
that NREL has is a really good point. The Department of labor has a really good one.
Federal Communications Commission, we were lucky to have some strong support from our
General Counsel and other agencies have been able to copy and paste, and I really recommend
doing that. Imitation is not only a sincere form of flattery in government, it is actually
the right move in this case. >> If you go to GSA's GitHub account, you
will see developer pages. It is actually just a running list of the API hubs from across
government. And please do look at these as examples of president, and then go into likewise,
and let me know when you get your developer hub up, we would love to add you to this list.
>> So the next question, and Nick, this gets back to similar what you were talking about
that a little bit different. That is around your actual world -- actual developer hub.
What are you using for your platform at NREL ? Is it [ Indiscernible ] or something else?
>> So, it is something else. I mean, our hub is basically this API Umbrella platform that
we have open sourced. In that hub consists of the documentation management, and then
part of that is also sort of this system that we have in place to deal with the API sign
up , and also applying that across the board to all of our APIs, authentication and rate
limiting. And analytics. >> So, this is a custom solution that we have
developed, API Umbrella, a lot of this stuff was not available when we started a few years
ago. But on the back end, our actual services are written in a variety of different platforms
and languages. It ranges from Python, to Java, PHP, etc. But, that is on the actual services
side. Our platform is this API Umbrella system. >> The question I actually have is, is API
Umbrella actually generating this page in these pages?
>> Yes. So, API Umbrella is split into several different components. Basically, there is
the web component, which is basically just this documentation system. And then, there
is a routing component that acts as a sort of our gatekeeper to allow access to our actual
back and APIs, if that makes sense. But this is actually just a rails application.
>> The question I have for you is, how did you actually go about building the team of
people who are doing APIs across NREL ? Do you have a working group that you use with
other parts of the agency or what? >> It is P informal, actually. You know, -- it
is pretty informal, actually. You know, there are actually four different developer teams
within NREL. So I don't know how many there are in total, maybe 80 people in total. So,
it is not a huge group. And we tend to work fairly closely. You know, we always work better
together. But, yeah, it is somewhat informal. Each group has sort of gotten these demand
and requests for APIs , so we have just sort of set about collaborating and building this
stuff from there. Just sort of as the need arose.
>> That is awesome. I mean, one of the things I think is definitely going to be up and coming,
and we have already seen this with api.data.gov, and we will continue to, and that is how we
all start interacting with each other as agencies. I know one of the things that happened over
at the Federal Communications Commission is, when we were building the national broadband
map, we needed an API for a census block conversion. So, you could give it a address or latitude
and longitude and it will pay you what census block you are in. And the raw data from the
Census Bureau existed from that. It was static and you have to download it. But we needed
an API . So, we built an API, and it has been one of our more popular ones.
>> But it served a purpose for us, and actually, we have been able to, some other agencies,
have used it for their applications as well. But you know, that is something which in the
long run, I imagine, this census is going to cover as well and, you know, there is a
lot to be said for each agency standing up there APIs of the content and data so that
we can build off of it with each other. And how we start to go across that I think has
really worked well. >> So a couple of more questions. Oh, sorry,
go ahead, please. >> Related to that, one of our earliest adopters
of APIs was another laboratory in the Department of energy that needed our data. They were
an early data tester of all of that and we were needing data from other laboratories,
and they have released APIs recently. It's very nice for everybody has APIs.
>> A couple of more technical questions. What is the cumulative size of the data that you
are providing access to, in gigabytes? >> So, our data I think might be a little
bit different from a lot of other people's data. I mean, maybe not. But a lot of, for
example, our fuel stations, that is more of a simple case. It's not very big. Maybe like
10 MB of data, if that. But we have a lot of other stuff, like a lot of our solar services
which provide more fancy, scientific modeling. We have a solar service that basically, given
any latitude and longitude in the US, it will estimate the solar resource in that area.
>> If you were to install solar panels, what could you estimate would be the output? What
is the estimated price? What is the payback period?Those servers, I mean, we have almost
a terabyte of data that we have to aggregate through and run. And we are not returning
all of that data, but we need to process that data. Because we have basically a grid of
the whole United States, down to like 5 km, and what the solar resources are in each of
those areas. >> People are not really downloading the full
data set, but we are using a lot of that data to provide more of these more model oriented
services where we are providing more analysis results, if that makes sense.
>> Yeah, I think that is actually unimportant illustration, two. Of how important it is
for each agency to think of this pragmatically. About what are the use cases. For these Web
services. So basically, what are the different ways you can imagine and invasion a third-party
wanting to interact with the information of your agency? It is not necessarily straight
DB ***, so much as it is user experiences, or being able to do X, Y or Z, and think that
the goal of the APIs. >> Another question. How many concurrent users
is your system scene? How many total users? >> I would say, again within the past year,
we have only had 825,000 public API requests. That is not a massive number. But we have
made 29 million internal API requests . We definitely hammer it internally. You know,
we run big aggregation processes against some of our internal APIs and just hammer some
of those. As far as concurrent users, I mean, yeah [ Pause ]. It depends because our back
end is distributed through different users. We probably don't actually ever get that high,
maybe 5 to 10. But, we have benchmarks, at least the API Umbrella portion of it, and
that can scale to thousands, theoretically. >> The real actual services that do all of
that heavy-duty analysis work. >> So, I mean, from a similar perspective
with that, I know that the Census Bureau is a great example to follow for anyone. And
they did a really well flushed out API release . But also, for some data that is massively
popular, it is all significant stash they saw a significant spike after they deliver
the API. I think you are actually averaging about 50 calls per minute, I think. And that
is even after the fact. But I think it is important also to see this as infrastructure
building for the future. >> Once you make something available to the
web service, to your self and the public, basically, you can build on top of that a
lot more readily going forward. And so, even if something is less [ Indiscernible ] data,
it is still sort of worth shifting back to a service model. In the content, if you go
to the suggested readings section in the resources and tools, there is an outstanding read that
I would really recommend to all of us. And that is from API each evangelist, and that
is the secret to Amazon's success. Basically, every page that you go to on Amazon.com is
consuming its own internal APIs. And that stems back to, basically, about 10 years ago
when the head of Amazon sent a memo to the entire staff saying, basically this.
>> All teams are going to expose their data and functionality through service interfaces.
All the teams must communicate with each other through these services. You know, there is
no cheating, you can't, like, you know, do that but instead use thumb drives. They can
use any technology. But basically, they had to start doing services and doing them in
such a way that they could one day be made public. And anybody who does not do this will
be fired. >> And by the way, one of the comments that
just came in, from one of the viewers, former Amazon employee here, totally true story.
The mindset of a pragmatic shift to services first is a game changer. Because it basically
liquefies everything so that internal, external, everybody can start consuming it and building
on top of this in a much more productive way. >> And I think that is worth keeping in mind
when you're looking at what to make available via API. Because it should both be like what
are the most popular services, what do people want. But also, systematically trying to shift
your information architecture to one that is service-based. Because that has tremendous
long-term benefits. You will be able to maintain projects easier. You will be able to build
new products much more easily. The benefits go on and on.
>> So, there are no more questions. And, Nic, I really want to thank you for sharing. And
more so for being an example and government. You know, developer.nrel.gov is something
that we will keep pointing people to, and I think with good reason. And that is a fully
fleshed out, well-rounded dynamics. You know, model. So just basically, please feel free
to get in touch with Nick or myself. Like I said, Anna Tatian -- imitation is the right
thing to do in this. When your agency is getting started or continuing to move forward, look
at developer.nrel.gov, and look at other agencies. There are about 30 agencies and if you have
other questions, go to howto.gov/api, and if you don't find resources that support you,
put them in the comments and we will put them in. The next six-month strategy is actually
about this. This is what following through with the APIs requirements look like and we
want to work with you and partner with you on that.
>> So, thank you all for turning in today. This will be posted afterwards. Actually,
sorry, one more question in at the end. For internal API users with a greater access to
theater -- [ Indiscernible ]. I can definitely answer that. You have to take that on a case
to case basis. Sometimes, it is all public information anyway, so it does not matter.
And maybe you just allow higher rate limits for staff. But the fact is, you can definitely
build your APIs so that there is a certain data made public and other data that is kept
within the firewall. >> And please, more questions. Please feel
free to e-mail afterwards and we will be having more webinars in the future. But, all of this
gets back to, the next six months are about implementing. So please, get in touch, let
us work with you. GSA is here to support you in API creation and developer of the building.
This video will be posted after the fact on howto.gov, along with the others. howto.gov/training.You
will also be getting an e-mail prompting you to fill out an evaluation. We appreciate your
feedback. >> Otherwise, thank you for your time and
let's convene. This is going to be a very worthwhile shift.
>> [ Event Concluded ]