Okay, everybody, I'm gonna go ahead and get started.

I'm Kirsten Hunter.

I'll be talking about designing irresistible APIs.

For those of you who came to my workshop yesterday,

a lot of this is gonna look familiar to you.

But this is much more focused on the producer side.

Creating APIs that are gonna make

your developers happy, creating a successful API.

One of the main reasons I like to give this talk

is I gave a talk at OSCon a couple of years ago.

And someone ask, asks me a question about about performance and scalability.

And my answer was, if you don't make it a usable API,

nobody's gonna use it, and then you won't have to worry about scalability.

So, what I'm gonna do is I'm gonna try to help you understand

the things that you need to think about when you're creating an API.

So that you don't fall into some of the pitfalls that other companies have had.

I've been working with APIs for about ten years.

I worked at LinkedIn, I worked at Netflix, I've spent a lot of time supporting

developers and partners and trying to help them be successful with APIs.

So this is all based on problems I've seen with fairly large-scale APIs,

and I'm trying to give you the information about how to be successful.

My presentation style.

I'm using Haiku Deck.

It's a fantastic program.

It's an iPad app.

You'll see there will be pretty pictures.

That are sort of evocative and give you something to think about.

And there's just a few words.

I will make speaker notes when I put this on SlideShare, so that even

without my interpretive dance you can understand

what it was I was talking about.

When I put a lot of information and bullets on

the slides, what happens is, I talk a lot faster.

I read the slides to you, you read the slides.

And then it's like story time, and we all fall asleep.

So, what I want you to do, is I want you to listen to me.

And I also want you to ask questions.

I, I love making sure that the information I'm giving you is valuable to you.

So, at any time, you can raise you hand and ask questions.

There should be time at the end as well.

My handle on twitter is Synedra, S-Y-N-E-D-R-A.

And you're welcome to tweet you're welcome to ask me questions anytime after this, at

the conference or send me a tweet or an email and I'll be happy to help.

Okay, so, why do you wanna have an API?

A lot of the time what people hear is their VP says we need an API.

And so when asked someone asks you why you have

an API, the answer is cuz we wanna have an API.

Okay, so but a lot of companies have gone that route.

Netflix had the idea of, let a thousand flowers bloom.

If we make an API, people will use it.

It turns out, if you don't have a

directed strategy, if you don't know what the business

value is for your API, eventually someone in the

C-suite is gonna say what are those engineers doing?

And why?

If you can't answer that question, then you're, it's very possible

that your API will be killed or throttled back a lot.

It also makes it harder for you to communicate with your developers.

How you want the to use the API, what you want them to do with the API.

So thinking about that stuff ahead of time allows you

to make an API but is useful for your users

and also that you can defend to your management when

they ask you why it is that you have the API.

So I'm going to go over a few business cases

so you can understand what the sort of range is.

Mobile/Market Penetration.

so, getting yourself on mobile, getting market penetration.

Netflix is actually a great example of this.

Not the mobile exactly, but if you buy a device, a television, a DVD

player, a Roku pretty much anything but an Apple TV, it's gonna have Netflix on it.

It might have other things, it might have Amazon on it.

But Amazon has to work a lot harder,

because everybody expects Netflix to be on those devices.

Because they were there, they really pushed,

they work hard with their copartners to

make sure that they are the de

facto standard for streaming movies on these devices.

Drive Usage.

Twitter Twitter lets you use their website.

They like you to use their client, their mobile client, but

what they want is all the content that they can get.

They want people to engage with the content and retweet it.

They want you to share stuff that you find elsewhere.

There's a reason that there's little Twitter buttons, share on Twitter buttons.

There's a reason why they make it so

easy for developers to integrate Twitter into their application.

One of the things that they do is they, they do identity management which allows

more people to use Twitter, and then start adding to the, to the feed.

Adding good quality content about what people are thinking.

Defensive Strategy.

Okay, so this is, I'm, the example I'm gonna get, give is not exactly about APIs.

I can give you an API example which is Best Buy.

They wanted to protect themselves from Amazon

selling everybody all over the internet electronics.

With a Best Buy API you can see what's available.

You can sort of shop for things.

You can, and it's all very focused on electronics.

Circuit City didn't do that.

So who's doing better now?

And book, the bookstores are another great example.

So Amazon came along.

And Borders was like, yeah, whatever.

That internet thing is never gonna pan out.

No one's gonna do anything with that.

Barnes and Noble did a slightly better job.

They have the Nook, they sort of embraced

the e-book, as something that was important to them.

And they did put energy into their website.

So, now where's Borders?

they, they got eaten, by the people who were thinking about

what people were gonna be doing in the next few years.

Partner connectivity.

I cannot stress enough how important this is.

Federal Express FedEx has a lot of

competition, the US Postal Service, UPS DHL.

There's lots of people who will deliver stuff for you.

But FedEx was the first one to have a really good API.

Once you have caused a, a partner to integrate

with your system, with your API, they're kind of trapped.

I mean they could go, but there's more friction.

It's a little harder for them to leave.

and, and it's, this is a huge value for your business.

This might be the only value in your API, and it's huge.

If you can keep your big partners happy, and you can keep them connected to you,

and make it hard for them to leave, then your company's gonna do a lot better.

So, technical cases, Abstraction.

Reducing complexity.

In SendGrid, mail is really hard.

Sending mail, there's a lot of different

formatting issues, there's a lot of different clients.

So SendGrid makes email easy and

that's, that's their business, their technical case.

Simplify.

So Context.io also works with email.

What they do is they work on the client end.

So, if you have Gmail for instance, your ability to organize, and have activities

based on the information that comes into your email is, is limited.

Contacts.io I know allows you to make, make, make

applications that work with the things in your email box.

One of the hacks that I keep, keep threatening to make, that I

think would be hilarious, is, I wanna use contacts.io to look at my email.

And if one of my relatives sends me something that's on snopes

or an email that says, here's a chain letter send recipes to

all these ten people, put your name at the bottom, take the

name off the top, or you're going to burn in hell forever.

I don't want to see that email.

I want it to just leave my mailbox.

And then I would like it to use Twilio to call them at

3 o'clock the next morning with a very important message about email etiquette.

That's how annoying it is to me.

[LAUGH] probably that annoying to you guys as well.

Metered Usage.

Amazon, Heroku, these are companies where they charge

you based on how much you use the system.

This is actually a really great model for developers to use.

It's great that something is free, Heroku desk

have free tear for a very small amount

of usage, which makes them great prototyping and

having a system that is visible to the internet.

Amazon has, they charge you for how much

you use the S3 or the or the, the

service or whichever part of AWS you're using.

So this is a, this is, this is actually a modernization strategy.

You'll notice I haven't talked a lot about modernization strategies.

And part of that is because well, Twilio and SendGrid, or SendGrid and ContextIO

and Amazon do have monetization strategies that are kind of centered around the API.

I still say that partner connectivity and some of

the other values are just as important for your company.

So, even if your API's not making money, that's cool as

long as it's contributing to the stability or growth of your company.

Okay.

All of the above.

So, Twilio.

Twilio will send SMSs, they have metered usage.

They make things, hard, hard things.

voice, and, and SMS are actually very hard things to do without an API.

But also have a, an army of evangelists that

run around to techathons and help people do it.

And they have one of the best developer experiences out there.

Their goal is, if you go to their developer site

you can make a call, a successful call within five minutes.

If they don't meet that metric, they try to make their documentation better.

So, Twilio's money, monetization strategy is their API.

They don't have any other way of making money,

They are developer evangelists working in the marketing group.

But so that's another sort of technical case.

When you're building an API there are eight architectural considerations.

Affordances, what do you want people to do with your API.

You need to think about what, what kind of client do you want people to make.

Are you trying to make some internal clients and some external clients?

Are you going to have a website and, and mobile and that's it?

You need to understand what is important to you.

If you're trying to drive usage, then you should make

sure that it's super easy for people to drive usage.

I'm going through these things kind of quickly, because I'm

gonna, at the end, sort of give you a process that you can use to

take these ideas and create an API that is useful, meaningful, and successful.

Your Schema.

It's not as important as it seems, I think

of the schema as important only in that modeling

your schema deliberately and explicitly, allows you to see

where there are holes, where you are being inconsistent.

You want your system to be consistent, easy to use, and, and complete.

And it's okay for your schema to

have to-dos, just like in test-driven development.

It's okay to say, when we get around to doing

the profile stuff for the users, it should have this architecture.

In terms of, of, how to organize them,

I do tend to like it when resources are two levels deep.

So five plus or minus two is is the amount that people can remember.

So, you know, three to seven top level buckets and then the things underneath.

That's actually not important for the usability of your API, but it's

important for the developers to kind

of understand how your information is structured.

And how to think about, creating a product from your API.

[SOUND] Who Can Do What?

.

Okay, a lot of times, people mix up authentication and authorization.

They use the same word for the sa, both different things.

So, if I have a driver's license that says I'm 19, that's great.

It, it identifies me, it's a thing.

And can I buy cigarettes.

But I can't buy alcohol.

All right, so, I'm not authorized to do all of

the things that someone else with a different ID can do.

There's different ways to do authentication.

OF allows the user to use an identity that they've

established elsewhere and give you permission to act on their behalf.

In your application.

One of the things that people don't realize is if,

if identity isn't one of your core competencies, if you're

not super worried about security and privacy, it's sort of

a fun application, you can actually use some of these providers.

LinkedIn, Facebook, Twitter, you can log in with, a lot of people log in

with those services, even if you're not interacting with them in any other way.

This allows you to focus on the core, competencies of your application.

The more things that you can outsource to other systems, especially

when you're trying to get, first thing out the door, the better.

authentication, and authorization, it can be things you can do.

But it also can be

how many times you can do them.

So, most APIs have throttling limits.

Those throttling limits are based on a couple of factors from the business side.

Search is usually throttled for a couple of reasons, and

it's usually more heavily throttled than any of the other resources.

One reason is it's expensive.

You can't really cache search results.

People are going to search on new things.

So it's going to hit the server every time.

And that's the same search server that you probably use for your main product.

So you have to be pretty protective of that

and make sure that people aren't abusing that resource.

You don't want to bring down your main product by, by third party actors.

But the second reason, and something you need to realize,

especially if you are working with you know, the C suite.

This helps you protect your data, your data is likely your intellectual

property, the thing that makes your, your system important to people.

So by limiting the number of times people can do searches you make it

much more difficult for people to rebuild

your database elsewhere and compete with your product.

Sales people will generally think that if you have an API, everyone

is going to steal all your data and make a competing product.

That's very rarely the case.

If someone wants to do that, they'll scrape.

and, there's ways to get around that, but, the

API is not actually a vulnerability in this case.

[SOUND] So, building a successful API.

First, your API is a product.

Your API needs to be a first-class product.

You need to treat it like, as, as,

as something that's as important as your other product.

You need to not try to slap it on.

Okay so, a lot of times especially in really big

organizations what happens is people say, oh we need APIs.

So what we're gonna do is every time a developer makes

a thing, not only do they have to make documentation which

they don't wanna do or tests which they really don't wanna

make, but also they now they have to make an API.

So usually, they'll like shove it through some library that spits out an API

that doesn't really have a purpose other than being a check box for that developer.

That developer's not thinking about the end

user, use case, they're just thinking about

making an API because that's on the list of things they have to do.

They're being measured on writing code.

Usually they are measured on the quality of there documentation or tests, and

when we have APIs, they are usually not measured on the value of those.

So we end up with a potato and a bunch of really

ugly sprouts, that are not related to each other in any way.

It's hard to use, it's ugly, and it's not going to be successful.

I'm gonna talk about API First.

You'll all be like I can't do that.

API First is the idea that everything your company does should go through APIs.

Your website, your mobile devices, any other products, your

API should be the point of truth for your company.

That means that if you add a feature to your website, your

API has access to it as well, your mobile device automatically has it.

You don't have duplicate code in two different places.

Worse, is, the, the, the worst part is

that usually, the duplicate code isn't exactly the same.

so, the API does things slightly differently and when there's a bug

in the website, there's probably a similar bug on the API side.

But but it doesn't get it doesn't get fixed.

I, I refer to places where the API is not a first class product.

People who don't use API First as, worlds

where the, the API is, is sucking hind tit.

It's the ninth puppy, there's no milk.

It has to wait its turn.

And the idea is, developer makes a new feature on the website, great.

The product is good.

And then when he has time, do himself, extra

spare time as all developers do, all the time.

He's gonna go over and make a meaningful API that meets that same future need.

That doesn't happen, it's not reasonable.

And whenever you try to slap an API on as a side thing.

You're going to end up with bugs.

You're going to end up with a very difficult to maintain

API and it's not going to work as well as you'd like.

So the first thing you want to do is figure out what your Business Value is.

So I talked about a few different things driving usage.

Do you want people to.

Interact with your system more often.

If it's a social s, sorta site then

yeah, you probably want people to access the system.

And, and learn, and, and read and, and write to it.

So that might be the business value.

Getting new users, that's, that's a value.

All, always think about those partners.

If you wanna be a successful company, you're gonna need to

partner with and really support some of the larger companies like Microsoft.

Microsoft, expects well formed APIs.

They're very smart.

they, they push really hard.

So, depending on your business value.

I mean this is what should happen if you

stand in the elevator with the CEO for 11 seconds.

And he says, hey what is it, we have API for anyways.

Partner integration.

Driving usage.

Modernization is rarely what you want from your API,

but if you have a plan for that, that's great.

So you have to have a business value.

And from that business value, you make some use cases.

If one of your use cases is mobile, that rest potato, is not going to work.

Because what that rest potato usually ends up

being is your database schema barfed into REST.

And a mobile developer wants to make one call per screen.

They have to deal with the fact that a user's

gonna walk into an elevator, or drive into a tunnel.

So they can do a retry if they're making

one call to get all the information for a screen.

But they are not going to want to make

50 calls to get all the information they need.

So, figure out what your use cases are, what they have to look like.

Those are the things that should be super easy to do with your API.

I'm gonna tell you here, following the REST guidelines as you

understand them is not necessarily going to be what you want.

You need to understand what your customers want.

You need to think like your end users.

And you need to have use cases

that you understand and that your developers understand.

And then here is another thing that's gonna help you with that C-suite.

Measure success.

What metric are you using to measure success?

Your business value is usage.

Great, count how many times people do things on the API.

Your API is gonna be cheaper than the website.

If, if there's a configuration, a form on your website.

And you have an API, maybe what you're gonna measure is what

percentage of, of changes to the configuration are made by the API.

And maybe we're gonna try to drive more to the API.

It's cheaper, it's actually easier for your partners to automate.

And when I say partners in this case I'm also talking about third party developers.

You wanna, even if they don't have a, a

monetary contract with you, you wanna treat them like partners.

copy.

There's some really fantastic APIs out there.

They might not be exactly like yours, but you can

learn a lot by looking at APIs that are successful.

Twitter's a great example.

They're, they're developer portal is really strong.

Sometimes you want to have authentication and the best

way to do that is to use existing libraries.

Don't try to build everything from scratch.

Go ahead and use other API's if you need to.

Just be aware of the vul, vulnerability that you have and have

a strategy for what you will do if that API goes away.

The developer experience.

This is one of the things that will drive the success of your API.

And I'm not just talking about external APIs, I'm talking about internal APIs.

Even, I would say it's even more important for internal APIs.

Because if someone is forced to use your API and it's a difficult experience.

They're still forced to use your API and you're gonna have

a lot of support debt that you'll have to deal with.

You want to document it.

You want to make it so that most of the time they can just do what they want.

It's quick, it's easy and they don't talk to you.

When you have open developers what you have to remember is

that open developers are like wild animals on the Savannah.

Wandering around looking for a watering hole.

So they're gonna give you about five minutes.

They're gonna come in, they're gonna think, What?

But, what is this thing?

What can I do, and how can I do it?

And why, like, what problem can I solve with this?

You need to make those things really easy to understand.

And again, Twitter does a really good job of this.

Twilio does as well.

And, I encourage you to look at some successful

developer portals to help make a great developer experience.

Communication.

So communicating with your developers is critical.

Don't just tell them what your API does.

You know what your business value is.

You know how you're gonna measure it.

You know what your use cases are.

Those three pieces of information are not going to

sync your company if you share them with the developers.

On the other hand, what they're going to do is they're

going to convince those developers that you have thought about this API.

You have plans for this API.

This API is a real product.

They can use it.

They can trust you.

There have been many cases in the past where

people have made APIs without a real good strategy.

And then people used it and they sorta made modernization things.

And then, the API got shifted or pivoted or whatever, and

all of a sudden it wasn't available for the developers anymore.

So the developers who had invested their time in

using this API were kinda shot in the foot.

So you need to build that trust.

And one of the best ways to build that trust

is to tell the developers why you have an API.

How you're measuring success.

What you're trying to accomplish with it.

Show them the use cases.

Make those tutorials.

Give them example code that works.

In as many languages as you can.

Encourage your community to do that as well.

Marketing to developers is different than marketing to regular people.

Regular people, you show them a pretty picture of

a ketchup bottle or whatever, and they're like, [NOISE], ketchup.

Or bacon, bacon's always awesome.

Developers want to feel engaged.

Most of them are gamers of some sort.

They enjoy leveling up.

They enjoy feeling like they've accomplished something.

It's one of the reasons I think Twilio has such a great onboarding experience.

They want, within five minutes, for you to have done a thing.

Created a call that works.

Because now, what's happened?

You're invested in, in the API.

So that five minutes that you were gonna give

them, now it's turned into a half an hour.

And they, the more it feels like play.

The more likely they are to stay.

The more it feels like work the more likely they are to go do something else.

I wanna give a shout out to Firebase.

They have a great tutorial system for learning how to use the system.

It feels a lot like Codecademy.

It's it's very step by step.

When you make a documentation, you also want to think

about how the developers are going to get to that documentation.

So for instance, Hiroko.

Which is a fantastic product.

All their tutorials are about 17 pages.

Just a whole list of how to do things.

It's exhausting.

And the problem that I have had is that I can get through about maybe a third of it.

And then, something that I, in my real life comes and I have to deal with it.

And then I go back and I don't know where I was.

So break it up into chunks.

Have tasks.

And at the end of the task, it may seem

really stupid, but be like woo-hoo, you did a thing.

Now you can go on to the next thing.

Make a choose your own adventure.

Make it feel like they're advancing down a path.

When you look at the 17-page tutorial, you don't feel like you've

accomplished anything until you get to the bottom of the 17th page.

That's a little demoralizing, and it sure doesn't feel fun.

Tools.

There's some great tools out there for API exploration,

IOdocs, swagger if you have your database schema modeled,

effigy has a console.

It doesn't really matter how, but you need to make

it easy for people to see what a call looks like.

there's, there's also Runscope, which allows you to

sorta watch how traffic works on arbitrary APIs.

And API tools from 3scale [UNKNOWN] can do the same thing.

So, figure out how tools can be used.

Give people little, little how to do it guides.

So that they can explore and see what they

can do with your API without having to write code.

Asking questions.

So this is not your problem as a producer, except you're supporting the developer.

So one of the things software overflow actually has

a page that tells you how to ask good questions.

And it's not quite clear enough.

So I try to communicate to anyone I'm

trying to support what a good question looks like.

And a good question looks like a good bug report.

And it is.

I did x.

I expected y to happen.

To my dismay, z happened instead.

A good question always has all three of those things.

And the reason, you'd think, well, okay, I, I get the, I get the A and C thing.

Like I did this and that happened.

A lot of times your users will be

really frustrated, and they'll be like, it crashed.

Okay, well, well, what were you doing at the time?

And then they'll tell you, well, I did this and it crashed.

And you're like yeah, that's, that's actually.

That's what I would expect that to happen.

So you want to know what they did,

what their expectation was, and what the result was.

Maybe there's a bug.

Maybe they're using a different resource than they should be using.

The example I give so you can understand the

importance of this is, I jumped off a cliff.

I expected to sprout wings and fly.

To my dismay, I plunged to my death instead.

Okay, not a bug in gravity.

A problem with my expectations.

But when you communicate with your developers about asking questions,

you want to tell them, if they have an incorrect expectation.

That's a problem.

It's a, probably a documentation problem.

A communication problem.

You should have made sure that they understood what was going to happen.

So encourage them to understand that they're not

stupid because they're expecting the wrong thing to happen.

You just didn't tell them what was gonna happen.

So you'll fix

that.

SDKS.

All right, John Chian is gonna talk later, he's probably gonna talk about them.

I do not like SDKS.

For API's.

And the reason is if your API needs an SDK, you're doing it wrong.

You're API is not well formatted.

It is not created well.

It's not easy to use.

The more levels of abstraction you put between the user and

your API, the more places a, a of potential failure there are.

And, and it's, if you created a good API you don't need an SDK.

And also once you start making SDKs you

have incurred a huge amount of technical debt.

Because every time you change your API you have to change all

12 of the SDKs you have for all of the different languages.

Make is so that someone can write code in a, in any language HTTP

is well supported in, in all modern programing languages.

Make your example show them how to use just a basic call.

You may have to give them some help with

authentication, that is a hard thing to deal with.

But don't, don't try to wrap the whole API in

an SDK so that they aren't actually touching your, your API.

Because you're gonna end up supporting two sets

of things, and, and it's gonna slow you down.

And it's basically just evidence that you didn't

do a fantastic job of creating your idea.

Okay, so just like anywhere in the on the

internet intelligent conversation ends when a cat picture is posted.

So this is my cat picture.

And I will open up the floor to questions.

Again you guys can tweet me or you can ask me pretty much anything about API's.

When I say I worked with them for

ten years, I've worked with them for ten years.

I have seen everything on the consumer side and the producer side.

And I probably have an opinion.

[LAUGH] But I'll share it with you.

So, are there any questions?

Yes.

>> Do you have any wisdom versioning

an API or rereleasing versions with recent changes,.

How do you, kinda deal with that from a, from [INAUDIBLE] aspect.

>> So there's a few different ways to deal with versioning.

So people put a version in the URL.

Some people put it as a header.

Some people put it as a parameter.

How you do it is not important.

That you communicate it clearly to your users is important.

I caution against putting things in headers when you have a large group

of people who are not fantastic developers because it is hard.

In a lot of languages.

One of the problems that I had at at Netflix was that

someone wanted to use the Zend framework, which is a PHP framework.

And it made it pretty much impossible to add headers.

So that's how you can set versions and what I tend to think the best

strategy is, is to have your default, like have a, not use the URL.

But have a default.

And tell people when you're going to change the default, and

tell them how to go, how to keep using the older version.

Move the default forward to the new version.

So that new people get the new version, and

the old people can keep using the old version.

I'm frequently asked how to get people to move from

the old versions so they can get rid of it.

That's pretty much impossible.

Somebody had a task six months ago, they fixed, they, they, they met that task.

By using the first version of your API.

They have no interest in going back and writing more code.

They, they probably have forgotten how the code works at all.

And you can't push them.

But what you can do, is you can try to pull them.

Maybe version three of your API has a subscription

service for the stream of activity, and that's super awesome.

And maybe that's so awesome that you'll get

people to move from version one to version three.

But you can't count on it.

You can get deprecate APIs, Google does it.

You can deprecate old versions of APIs, but you will get pushed back.

So you, you need to, this is one of

the reasons of measuring APIs, this is really important.

You need to see which of your customers is is, is still on the first version.

So Ken Lang, the API evangelist, worked with a company who had different versions.

They had like four versions.

And only one customer was using the first version.

And he's like well, We can shut down the first version, right?

And they were like, Why don't you see who that customer is.

And that customer was bringing in $600,000 a month.

Okay?

That, that makes it worthwhile to keep that API around.

So it's not an easy thing you wanna try to prevent backwards incompatible changes.

If you introduce those, you're gonna need

to, to default, change the default more carefully.

Adding things is usually fine.

Removing or changing existing things is difficult.

So that's kinda the versioning thing.

You had a question?

>> When would you classify an API as failed on.

[INAUDIBLE].

>> It depends on the API.

If you give a very complex search query, that can take a while.

You do want to communicate in SLA to your developer.

The developer partners that you have.

And tell them what they can expect.

you, it is your job to try to make it as efficient as possible,

but you have, there's a lot of factors that you can't control.

You can't control the mobile device, its, how big its connection is to the Internet.

You can't control.

You can't always control the back end resource sometimes they get bogged down.

As an API developer you're kinda working with some back guys

and sometimes that search is going to take a really long time.

You can cash what you can cash and that's useful,

but there always gonna be times where things take longer.

So communicate with your developers what you know.

And if they tell you something's a problem, try to make it better.

[LAUGH] That's, I mean, that's, that's really.

Or just tell them that you can't.

Be honest with your developers.

Tell them the truth.

That's one of the problems I've had in the past, was when I wasn't

able to give developers honest answers about why things were the way they were.

And I think developers are grownups.

And we should tell them, hey that, that's there's a business

reason for that, and we have to do it this way, sorry.

Any other questions?

No, yes, Adam.

>> So you're anti-SDK, but what if your develops are pro-SDK?

>> Then they can write one.

[LAUGH].

>> Okay.

>> I mean, I, I, I think their parties at the libraries are great.

But I don't want to own it.

I, if someone makes a great API, a, a great SDK for my API.

And they support it consistently then I'll point to it from my developer portal.

If they make an A, an SDK for the API and they don't

keep it updated and they don't support people who ask questions, I won't.

I'll just tell them to use the API directly.

I always encourage contributions from community members.

I love it when people make great third party libraries and

they usually will, but you have to have a standard, a bar.

For, for something's that it, it, if something is causing you more support

problems, then cuz the user doesn't think about it as a third party thing.

So if it's causing you more support problems than, than

helping people, let people find it on their own [LAUGH].

And, and just help the, you know, have them sniff the HTTP traffic

and see what's actually happening, so that you can help them debug the problem.

Yes?

>> For someone just diving into API development for the first time.

Do you have any specific resources that

you recommend for somebody just getting started?

>> Oh, that's great.

I didn't even throw her, she like, threw me a soft ball.

Okay there is a site, apicodex.3scale.net.

It is a site that I put together when I worked at 3scale.

The goal of that site is to actually give you answers to questions about APIs.

High level design they are written by some of the,

the smartest people I know who think a lot about APIs.

Mike Emson has a lot to say about hypermedia.

he, he is very eloquent.

Kim Lane, API Evangelists, thinks about a lot of things.

So that's a good place to go.

and, and if you don't find what you're looking for

there, pay attention to the people who are doing the writing.

That I thought were good enough to put in the API

codecs cuz it might have written something about what you're looking for.

Understanding who those au, authors are that are leading the

API maturity, will help you to, to find what you need.

And you can also tweet me, or send me an email.

Oh, so contact information for me.

As I said, I will post this on Slide Share with, with speaker notes.

Links to the things that I talked about that I remember.

You can tweet me.

@senedra.

You can send me email at senedra@gmail.com.

And I am princesspolymath.com.

So, you can go there.

I'm actually gonna put up a worksheet.

A cheat sheet of the things I talked about at

my workshop yesterday and the things I've talked about today.

So you could just download it, or click on the links and go visit the places.

I will be at the meet the speakers event,

with my drone that I used for my workshop yesterday.

So you can come play with the drone.

Trying to suck away all the users from the other speakers cuz I like to be cool.

Plus, it's my drone, [LAUGH] so.

anyways, so that's all the questions I'll take.

But please do find me.

Contact me, over the internet.

Find me here.

And have a great rest of the conference.

Thank you.

>> [SOUND]