Merken

Do Users Love Your API? Developer-focused API Design

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and the and and so on and so on welcome thank you for coming and of everybody enjoyed idea Jägers keynote our already to build monolithic way maps and were talk today about API design and specifically API designed this focus on the people who actually have to write code against that API problem we are not going to be doing any coding at all today and implementation is an implementation detail so um don't worry where is going to design a really well in implementing it is somebody else's problem
at my as the alley undeleted here MailChimp about MailChimp is in an e-mail service company and we will tell you much more about it later I'm OK Holland I'm my engineering International champ graduate converge techniques e and after you graduate from the physical unity that going to come back to milton and work therefore you and your of version 2 . 0 of our API did a lot of things well and about 250 thousand users I hit it every single day and billions of requests come come and go and it's fairly popular and we did a survey not that long ago when we found 75 per cent of people thought that it was good or excellent which does a really good numbers but as we were working with it ourselves we discovered that there were some pretty big issues with the with the design of it and with the things that people try to do with it and and so this talk is sort of uh came out of that process of us by designing a new in the newest version or API which is currently in beta and it was supposed to be released a month or so ago and but software happens and so it's late uh we're also is the fairly interactive session so that during several portions you're going to need to probably chat with your neighbours and so if you would just take a moment introduce yourself your neighbors any new neighbors you don't know you're going to become good friends by the end of this so just make yourself from and in the and 1 in the generation and the generation of content and you think that would like and like to have a relation on from my perception is that this 1 1 in around like this and you are any meaning OK OK OK not that regulation on it and OK I want to bring it back bring it back bring it back a lot of room already I in often lost it by so of so all probably at least kind of AVI is already but it stands for application program in the face on it has a pretty much everywhere i if you've done any programming at all you use an API on because that's just interfacing with that program for an API is just going to be is isophote communicate across boundary in there are all kinds of different boundaries
everywhere you look at really blocks are an example of a boundary and language features typically are API is of that language a class methods more generally object-oriented programming from all the classes that you generate expose API eyes and then of course the thing that we're here today to talk about that web services and they could even be micro-services if you want them to be as high so and the is the principles that you use to to design of of a web service API odd they're going to be very similar to this the principles that you'd use design any other kind of API i will be using a Web services as sort of the the thing we talk about that
and there was no I don't know is it possible to the noise yeah have been the I guess it's hard to read in the in the light is that the and here in the spring is harder in his for the it it will be my 1st and so while working on that I'll just keep on track and I guess I developer focus API is and this sort of near the uh the movement we've seen over the past who knows how many years to bring user experience in web apps to get to for that to be a focus I guess and I've noticed that that hasn't really vineyard in API designed an API is still very much to serve the wild west in terms of how they look at and so when we talk about global focus they get as our time optimizing for the end user and not for your back end systems that many API is a design to make it make it easy to implement and maintain but they're not necessarily easy for the end user to use and when you focus on the end user the person is going to end up eventually using your API at that leads to great experiences in developing and so what developers want when they're using your API well if you try out anytime you use natural API that developers want to basically 1 thing they want to gain and they wanted done and I want to get out and they never want to touch your API again ideally dealing that is that the thing that they want most is to just get their their their sprint done and be done that be a version of the yeah I think it's but the
so never return is sort of an important part of that all on the other because because once they write something using your API you can just change how it works then your break everybody's everything there'll be sad on so you've diversionary eyes which is really important on but also the versions that you put out have to be like robust and functional but the so who here has had a bad
API experience raise your hand show of hands alright so a couple of you and good so a rule so uh for a moment for let's say 90 seconds talk with your neighbors about what made those experiences that what was it about the API experience you had made them challenging and when you're done I'm going to ask you to actually contribute and raise your hands and tell us what what it was that he thought and they're like never going to find and the mind and using ontologies and it and this and this and this and think about it and I really think it's kind of like that might not want to do this and you have might knowledge in this kind of studies and the model was like what you what you want and you will find a lot of the time you read the following you that the time and that's all I can think of the the thing is that I was going to send us the weighting the mean and and and you can go over the rest of his life and that of some of the Montreal and our learning and so we don't have 30 seconds here and then we'll probably have in common that down by 1 out of it and it is the it it is good and OK I bring it and for all i so raising anserina try not to name specific companies in the can way that we use by can you they can all business about like some bad experiences you have a pleasant and why they were bad the 1 who the all the thank you I'm going to want to use of all of the and stuff like this this sort of thing so you the I get and so we have in the back we get call used to create data that we got that XML front um and documentation that documentation at and the and when stealing my future slides 2 of the 1st things to of and the in the OK so yeah that's and they're all other things there so I'm creating resources that don't give you the resource back and then and then you getting make another call to get that resource so lots of API calls to the 1 thing much no the of you have to and the and structure if somebody from a lot of it was going to repeat just like a lot of baggage it does a lot of extra stuff the thank why why would that be a problem without the payment system in a sandbox mode of the Michael in front and the Steelers at a string it's the actual structurally event so schema API as I'm sure there are thousand more ways that we could probably felt that the rest of the our just talking about things that event but the short version I think of a lot of what you're talking about is easy stuff is hard the too many endpoints simple stuff is complicated and the doc stronger complete meaning a wrapper libraries there's some other things said at but yes that's that's a bad experience and on who raise your hand if you think you use more you have more good API experiences than that experience greater hand right well that's more people than I thought would raise their hand but it's still not very many so have the on so today what we're doing on our hands on design work is using real MailChimp endpoints on wearing a start running a little bit about MailChimp on you can't design of API without knowing the product that the API is going to be used for probably really well on and you also can design a developer focus API without knowing what the developers are going to use the API for also probably really well on and like the width of the degree of new wants not just like all they can do this but like more specifically what is more likely to happen and so that brings us to our advertising portion of the of thought has notably service writer our mission is to help people send the e-mails and 1 of the reasons that we have an API is that well or whatever co-founders along long many years ago 8 9 years ago I guess so story where eta 9 years ago he was a fork in the road began to choose to hire a developer to build an API for this new e-mail service companies or do I higher sales person but fortunately for me I he decided the higher developer and currently MailChimp has 0 sales people so seems like a good decision I so um
water main features lists campaigns and reporting and whose idea who reasoning to what is sending and what are people doing with that I guess I the other thing that we that we need to talk about it who uses the API MPa MailChimp our particular use case there are a couple of different options out there are people who use the API directly to your company wants to get your own data into MailChimp or vice versa are mobile apps are sort of an example of that but then there is the case where you might have data in a third-party party Web service that you want to communicate with MailChimp say your CRM or or your shopify shot and or whatever else and so the are also enables that level of communication where the user is not user might not even know than API calls being made but on the back side there are 10 of them the I
usage patterns um the that is about roughly that's about a week worth of API calls to version 2 . over API and that's how they break down and the overwhelming majority is list management getting people on was getting people off the list reporting is a close 2nd and then campaigns which is probably the biggest thing that MailChimp does if we didn't have campaigns like what would we do that almost nobody uses that the DAPI and so you have to kind of all I have to ask myself like is that because that's just not something people want or is it because RHI so bad that they can
so if we're gonna look at API 2 . 0 is list management end points on what we saw is that that is the most important the most traveled part of our API on so we've got these and pointless we're going to attempt him out right so what we what we would ideally what you'll do is out in a network to go over the list management like a little bit more detail what list management means that Milton and out while we're going through that keep a hypothetical company in mind it could be your own company and could be 1 that you've just made up and like so for example will give you some examples of an online store that sells like pens and pencils and such an and then once you're done thinking about that so you'll have some time to chat with your neighbours and and the reason we did a print out instead a web pages because last year that the wife was not sufficient but the sheer it's great but there's still no sorry I OK so so yes so will talk well as management and then and will get will get to the meat of that you know showing you show your dirty laundry here and so we have 5 different parts of an list you obviously have to be will the editor list so if I'm adding people lists removing them from you also we have merge fields and merge fields at arbitrary data on that is set up at a list level on and then we also have interest groups which are booleans of like you favorite color was was 1 example of then you can set those ups emerge fields might be like a 1st name and last time they bought something from the store and interest group is is a little more of like the there are interested interested in managing subscribers is another big 1 getting people on the lists and off of the list and keeping those fields that we just produce a talk about keeping those up-to-date so did you change your name where did you just buy something in the store have you decide you're no longer interest in court pencils and segmentation once you have them on the list and you have all this data about them you then want to use that to send different e-mails as you 1 standard somebody's ball a pencil maybe you wanna send me well but a pencil sale at the having that the things that have and then once all that's done by your boss wants know about statistics and reporting in whose opening in his clicking and what links and and all that so that that is about male chimps list management in a nutshell and 1 thing I'll say is that we do have I don't know from this talk and then go try to use our API because we're leaving a bunch of features out in the name of simplicity but so I guess then we have to talk about what our intent and so among yourselves with your hypothetical companies in mind let's talk about what and what sorts of things might you wanna do with the API then as your hypothetical hypothetical Milton customer so it's what take soon minutes and talk about what the big things are and then we'll come back in just about so got yeah we this idea in on the link and and yes the and the last 1 and I like you really think so that I think it would be a probably a because the use and there it is it and I I kind of like the research and wonder about things that we don't have this kind of problem and I would be to it and it seems to be having and and and and and and that was kind of a long weekend and so although you hear from you sound like that that actually works and I was really the the the the thing where think of the underlying time looking at it and how much of that is going to rearrange the will and in the last we got the head and they were in the building where on the floor is being aware that the announcement here in the right way to do this reading and this morning and I was on the increase in the in the making of this and and while while expansion of internet now we can ride on interrupting a lot of you know that when you can just but on OK as a way of trying to finish it up I think you have a high let's let's talk about let's share with the group what sorts of things might you wanna do with miljoen who knows a thing nobody knows a thing OK well I sent an e-mail and that's a really good idea what else might you want to a newsletter OK but what about growing list management stuff up the history of the and that the of OK great that's a really common use case and what else 0 yes sorry SIDS I'm really about that when I'm somebody had his company's us for by something they then get registered on the military mailing lists and hopefully only if the check book says I want to and what else what else might you want annuities merge fields or any of that OK yeah so here we mean it the 1st of the the they share and we typically recommend that you not have more than 1 list in the 1st place and there are some use cases where you would want to but we can we tried that so we have the uh interest groups for so i and segmentation so what you would typically do is have both of those lists someone less and then I when you wanna send another just part of it you would segmented offer that 1 e mail but I'm definitely use case that that some people have when they have multiple lists for sure yes I thought it was the and on that's right OK great so be able to set somebody's interest groups as you subscribe and anybody else can yes sir I I we the story was and Sharp yes so that the merge fields being able to create those merge fields are creating interest groups the API and that's especially useful like here like I think you're alluding to if you create a new category for markers and maybe adding an interest group that automatically as a category gets created in your store hello identifiers to the rest of the the only the information that the quality of the it is a partnership cheers so like the inter your your internal right so adding your your apps local internal ID to their miljoen profile so that you can link those up when the data comes back 6 recall back what not and OK let's see what some of the some of the other things as I think we've covered almost all these and and so now we're going to do is we're going to pass out of these endpoints these are just was management and just version 2 . 0 and and what will do at all Cummins cycle is around and just take a few minutes look over it and figure out what might be hot hard what what about these calls the harder learner heard use or anything like that so and it was just the 2nd we use that as
a yes so what this is all going unmistakable Minnesota through the end points and the even by problems don't be shy we know this is bad Sherwood what's what's that about you have a word of what might be hard to work with the or otherwise I I view this understand what what's confusing alright so that the hand to go work and I was hoping so let's go ahead and let's talk together about what what's wrong with this and again don't be shy for abuse brutally honest you need everything is a post if last low right what house was run with it race a lot lots of points so many endpoints what else following he said you could do this at the Static segments and dynamic steak segments could really just be 1 set of n points and what else the last the API key is in the body of the request that's baddish right so there are a bunch of other points in the API The Pretended with campaign or whatever so that is maybe more of an inward artifact of and of our own right so so I know context so as documentation the handout is really awful and I'll give you a hint that the documentation and website isn't much better in the back right so possibly the subscriber back subscribe to be the same endpoint that just takes more than 1 thing has a right away and aside from it just not being RESTful what's hard about birds in the world right OK great so will will talk a lot more about that in just a minute what else right so a lot of parameters for what should be a really simple called OK let's do a couple more what else do we have right yeah was how you where what happens there's I still struggle with that in this day OK interested persons interest grouping and it were were renaming and 3 . 0 4 exactly the reason practices right right but then the right yes so and there there's just some random hard limits in the activity and in the activity and point where it's like 0 to 180 days a why but why not 30 days why not 70 days right so the batons random point has a lot of like you to figure out how to scale this yourself and whereas we should probably do the scaling for you or just set a limit at a place where we know we can handle the volume so those are all really great and we could probably talk about what's wrong with this for hours I know I have a and so
so many methods of API key is a prior inconsistent naming and how you be merge fields lots of just lots of like it's it's hot minutes 2 pages to discover from you list and so
let's talk about other principles of developer driven API design and there are only in my opinion really to and you need to design for intent and you need to limit your API mental footprint how hard is it for some to load DAPI into their own brain so what is left of me so
if you look at this like if you thinking about what Google has in Gmail right maybe you you you got conversations and any of the individual messages in a conversation right arm and you could set this up in a variety of different ways you could make them completely separate calls you also there are things you want to know to make this particular screen happens so if you know that your intent is to make Gmail you know that you want to be able to get the subject but also of the Carter subject of the conversation but also a snippet of the most recent message and making both of those calls every time for every e-mail could be really a pain and a lot of extra things to do right you you end up with an impulse 1 querying situation where you have to get the list of conversations and then you have to make a query for every message when you design for intent you put that message in the 1st was that it's only 1 call the whole and box of that makes everybody's life of these on so look at this for a
minute and tell me if don't mean to try and see if you see what's weird about it on so that there's a light there offered for the air conditioning the light is on but the thing underneath the lights as a C all so the light is on when the air conditioning is off which doesn't really make any sense you're not gonna you're gonna look at that and say all the air conditioning is on because the light is odd because that's the way everything else works ever but no that's not how the sun phrase of you and in Atlanta of a light that tells you when you condition is often the summer is probably like how you might design it from the beginning but people got in your car and got into a million other cars in their level that exaggeration that got into a lot of other cars and every other car when the AC is off the light is off and so in this way like you don't want to be blazing new trails with your API most of the time and
so followed only and use HT basic off if you can if you can't use 0 off and use whatever version of the view that works easiest for you and acceptance adjacent who can think of a reason why you might not wanna use Jason there are a couple yes there and back right to use his you might need deserve XML and you might also know when he's Jason if you've got a ton of binary data and turning that into base 64 go you might so their reasons but start from the default accepting serving design and make your i API as RESTful as possible and we'll talk about that in a little more detail
surely and going along with the mental movement book primeur API abide by the principle of least astonishment HEV methods properly you JCP response could properly and as a call back to 0 1 agenda of the mentioned earlier please don't do that please you
got a 200 OK response code and then a success equals true please just just don't and that should be of 400 or maybe a 500 who knows who knows what's wrong with that it's just not successful the and then if you take nothing else away from this talk about developer of
API designed please remember this don't be clever 1 of them they
insulted somebody can give your API that it's clever and it needs to be accessible it needs to be easier needs to be simple and clever save that for I don't know when but please not for your API clever becomes confusing right and you want to be able to not read every documentation that has ever existed
right so suddenly 1 not all the what right so think about if you have a and and try to think about the cleverest thing I've seen in API but a lot of it comes back to using the standard properly and you can be clever by choosing like a really like all other use like for 22 is my response code because like the description of the 422 sounds sort of like what's going on and I don't know what 422 as I use like for 8 without prior right and so that maybe about example that might be the 1 on the so there there are some HTTP response codes for example that means something very specific and if a client is the following if you respect the client is then supposed to do something else but right like 0 well you and a good example of that the opposite of that is that if you tell somebody The method is available and it should return a the what methods are available in the headers and so you can imagine situations where you just don't want to do something that somebody is then going after reading documentation to figure out the and especially you don't want to do something that is clever that like somebody might think it does something else entirely because of the context that in but really it does this other thing and the I'm sure other people of examples of of cleverness in API is that it's painful probably even in milton's an API and and but we can I can we talk about that a little more offline after the fact if you and I can think of some better examples I'm so certain arrest so rest is an architectural style it's not a standard was coined in a PhD thesis on n the World Wide Web is living proof of the power of it that's why it works that's why we can do all the things that we do with it so if the World Wide Web work like
API is due trying to figure out where to go for lunch after this talk about would probably mean you'd of course what you do is you would pull out your phone book and you would page you turn the page to Yelp incorporated new call Yelp incorporating you'd say hi Yelp and I really need to make a search on your website so I could you give me a list of the the data you have available and how to access it and some nice person on the other in the form of say sure here are endpoints here's how you get them and then you would think say thank you hang up the phone and you open up sublime texture Adam whatever using these days and then you would write a client a web client for Yelp's website and that is how we write every API quite ever but rest helps the web make it so you open up from a new building any website anywhere and it works and so when people ask at all why rest that's why rest because uh at the network benefits of everybody doing the same thing the huge and if if it did work like that your desktop on your on your laptop I would look like the dust up on your phone if you were to click yes every time some website as students all the mobile app instead of going to mobile sites and so exclusively to the rescue there and so it should be at a
glance so on http at this there just a few methods right here that's kind of the point you've got you can create things using using poster on you read using get you can update using pasta applied on depending on the implementation and then on to is pretty obvious delete there's lots codes are also pre is set for you you buy accessory redirector in your error response codes serve time earlier it and you should return the area code because of the air that's happening or the success code if it was successful arm and not try to just trial not mixes up right an example here of of cleverness that just came to mind and there's actually a 400 error that says you were making too many calls to quickly on but with 400 hundred the the general idea is that if you get a 400 error you shouldn't repeat that I call if you get a 500 air tried again later and uh so you might if somebody is over using your API block you might think 0 it's clever also the 500 response could back because that'll tell them and you try again later when you're unblocked but 400 would be far more descriptive and would help them to understand 0 I'm actually doing something wrong here it's not the servants serves for so that's that's just 1 example became and so rest is an
architectural standard in 6 constraints so many of these you get for free just by using HTTP properly other core client-server model the stateless server and cacheability and layered system those are all basically if you're doing GP properly you get all those such as like 100 on and code on demand is what enables JavaScript and Java applets and whatever was the Microsoft trying to do ActiveX components or whatever and that's the code on command part of of on-demand part of as part of the spec but the thing that really like the reason we're here is the uniform interface and that is the part that makes said that makes or breaks a API really so the uniform interface constraint and you can think about in 44 ways at Resource Identifiers
everything should live in its own address and that is that the that the it works for developers because we're all well accustomed to file systems were well accustomed the things that are files living in certain places and so it it helps people understand your API better because it's something they don't have to learn all over again if you look at militants list API as a you to learn every single endpoint is to figure what anything that's and resource representations is the idea that a resource is not the same thing as it's representation and so 1 example of differ representations as you might serve XML you might J. might be the user's choice as to which 1 which representation their request and you get different language translations as differ representations of you really really even have different representations that do have different fields and then if you really wanted to so and so the 1 of the biggest part 1 of the places where the your API will fail to be RESTful if it if it fails 3 RESTful is in the self-describing message portion and typically and what our fielding recommends is that if you were going to have a self describing message you should register your own media type with the EIA and and you should do that and that media types and describe how to consume your API messages and we haven't done that version 3 point of milton's API yet and in part because it's still in flux and but also because if you get agreed that media type I mean you might as well read anything else and and so we use a on schema we passed back a link to the jason scheme that describes the document that you received in version 3 . 0 and API 2 . 0 fails because in order to understand the response that you get back you have to go read a giant rigid documentation tools whatever field is and how profits and then hypertext as the engine of application state this is what enables the World Wide Web for you go . com then eventually find a restaurant to go to lunch time at which to go to lunch and and in API is this is sort of a is a sort of a controversial things and the idea of how yes and an API is that when you you can find anything in the API by hitting the root of that API it will give you back a list of links that you can navigate around from place to place just like a website and PayPal's API does this actually and the problem that you have with various if you if you abide by it strictly is that you have it's a lot of calls them to trace that API all the way back to the you know whatever some resource your operating on every time need to make that call and so we version 3 . are API we have various links we do not expect you for trace then every time you have a deep alternate we expect that you will bookmark a page inside of the bookmark a page to use the metaphor inside of our API but the links are therefore discoverability and it means that you don't have to read a single page of documentation you treat key you call the version 3 . 0 root and you can then navigate and see everything there is to see that if you add in reading a couple days on schema documents you can actually feel a pull API that having adopted and and that is what a
RESTful API looks like and the riches Richardson assuring model and describe this in a slightly different way around so if we start from the from the bottom you got plane all XML 0 and then the resources and the verbs and it's not until you get to the birds and had many controls that it's actually it starts to be actually RESTful right if you just have XML wages Exmouth resources you're not you're not RESTful you have to have the birds the controls at which point you get to this magical breast right and this is this is not to say the rest is the only way or the best way is probably the most commonly understood among web today and and so having a RESTful API confers a lot of benefits and but maybe
maybe this isn't you're sitting there thinking this is not what I signed up for right I just I did not want to spend an hour listening to people why the on about rest and but it's important understand if only so that when you release your API finally and some smug develop runt of let's not really RESTful you can know how to respond and you will we know what they mean when they say that and you can maybe say intelligently well we decided to deviate from rest in this way because of x y and the use case and if you don't ignore them which is what people so and so let's get let's get down to
business what's let's fix the mess that we had out you earlier and the and just to reiterate the disclaimer at you're not seeing the entirety of the male chimps system so don't if you're watching this unconference later or you all don't immediatly go then try to make API calls based on these stocks anything because it's just a subset and so let's go back in order designs API we have to think about what the intent was and so way we barrett-anderson get customers on to our list keep the data up to date and organize our lists and things and also you have status to make for Ross happy so we know it's going on on so is there a good reason not to use rest for this was management and point can anybody think of 1 now that's I think I think that's the right answer in my opinion that's the right answer there is no good reason not use rest for the set of n points so the where would we start just no need to raise your hand to shouted out where we start making this mess RESTful OK like the resources OK a subscription could be a resource a list list subscription what other resources anybody shut out list member would be a good when you could subscribe then by creating a list member so that's another option to having subscriptions as its own resource interest group and an interest grouping I guess if you gonna go that route but anyway what else what other resources might 1 have a user yet in the larger API a user might be a resource but OK well we got some other things and that static segments right that should be a resource a report that right so you it's the other stats of like the different reports and could each be resource that right yes so you there there is there would be an entire way that campaigns e-mails as their own resource and so you would also that we talk about merge merge fields those would be those would be resources on the list right but but there are also be resources on but each individual member then they have the data of the data values of those things and and so depending on how your use cases are you might actually have a and you might actually have a a some resource on each member that shows there are merge fields were shows the interest of things and interest groupings being the other and so as right to take a take all minutes and the and talk amongst yourselves about what what we we once you have those resources and what I wanna know is how if you were trying to subscribe 300 people were 3 thousand people or 300 thousand people to your list what would you expect that look like and what calls would you expect to make an honor hypothetical brand new API that we've just designed in our minds what what would you expect that look like take or if you know it is a way stop other head out what the right now OK good and so what might be the reason as so I I know what I was talking earlier about having a or when k was secular about having all of the data available in 1 call I got I got some dirty looks from somebody around of what might be a reason why you wouldn't want that OK sure so you might have some scalability issues with pulling all and sending at all what are the other other reasons you might not wanna do that service and in every lecture sure and that's that's definitely true on the right yeah that's right so if you're doing batch processing you have to have the same way to handle errors and if you send 100 thousand rupees by subscribers and 3 of them have errors or how do you how do you deal with that OK what I'll you somebody appear of 1 of its I guess right and so about why a wise duplicating function on your API potentially problematic lecture I see you might make it might be confusing if you have a if you go totally over water and designing for intent and you run the risk of creating too many points to many of our resources the people of learn and and that's where the sort of the trade off of this design happens so if you don't go overboard with designed for intent then you end up seeing the opposite problem which is to do 1 thing in your mobile at different 14 queries and your mobile developers come to you know you because your API as requiring was just too slow and it's and it's a shirt re read conflicts right right conflicts and if you do put functionality enables against the implementation details of like if I've got 3 different pieces of code doing this you gotta make sure your architectures such that you're not copying and pasting code all over Europe PI and so that two page that 2
pages that you've got in front of you and if you follow RESTful principles and
we talk about the the resources we just talked about with lists and segmentation and and that sort of thing it can be summed up like that you can end up with a what is that's 6 a half-dozen resources that you can operate on using very basic at http of verbs and you end up with a far easier than understand up there's still the issue of what parameters are passed what about what data comes back and all the so this isn't the full documentation obviously up but I hope that you'll all agree that if you see that this is far less daunting and far easier to and understanding navigate than the two page like 10 point font like mass that I handed you that we weekend you at the beginning and so that is 1 the gist of it and we are of getting very i want to leave a lot of time at the end of this for questions because I figured you will have very specific things and and so we're talk very briefly about how we work with API Version 3 a and both evaluating it and then some other implementation details in animal leave a lot of questions for you to ask of for your own things because we understand that this work for us and but you might be having in of problem how to how does that map onto your own and implementation so um and
so this is how we discovered that 2 . 0 was a mass of n so it doesn't look sketchy understand announced actually plate has to go she is been given an award by green University suggest actually receive it so that and it and so we had direct feedback from our users and we looked through our support requests and with a ton of them are we at through social media complaints and this sucks I'm having a hard time I don't understand MailChimp and sometimes those reuser error and sometimes those were mailed to bear that we actually sent out surveys and we found people reusing IPI especially the other web services there were integrating with MailChimp and we looked through we ask them what hard about it and because it as we sort of saw earlier most of you have more bad experiences than good experiences that with ABS excuse me that the poor user experience on API is the default so in my opinion if people don't love your API it's probably not very good the militants API is not very good and it was relatively well received 75 % people thought it was greater excellent so and when you're getting this feedback keep it in that context that people are over the moon in love with it there's probably a long way for you to go to get ahead of the pack and the attack is not a very good place right now so he definitely ahead of hints from usage patterns really really important gonna collect data LOD everything about your API and it sounds hard especially when you start doing volume but it's really important that you keep track of every call and as much data about the college you can and excessive calls to certain endpoints of relative to the customer size for example if we have a person with a 600 member list um and they're making 600 calls a 2nd this probably something wrong and nothing wrong might be that they don't understand they've made a mistake they don't understand something about the that it could be that were not enabling the really obvious use cases they need and utilize endpoints 4 key features like our campaigns are high error rates on certain endpoints for certain users can sometimes indicate that there's something confusing about that and then that really common but only specific queries so if for example you see the vast majority of your queries to a certain point include the same sort parameter maybe that are to be the default and so think about that and and above all when you're looking at usage patterns collect as much data as you can and speed curious browser everyone's well search in different ways and try to have some kind of easy easily usable dashboard i we pump all of our data into elastic search and then have that Nice dash 40 kind of thing on top of it and and so that really helps us to see the error rates and sort of pare things down differently and and then above all when you're looking at this data start from the assumption that your users are not idiots some of them will be but assume that they're not to start with and that will get you a lot of information and even people were doing things in what you think is a stupid way it might be because that looks like the best way for your documentation of from your and points and and then a couple of rules of thumb we have for for bad API design and the best way for you to find these out for yourself is to code against your own API eat your own dogfood as much as you can and if you don't have any internal need for using your own API somehow make some sample apps like do the work but do you have to make freak references to your own API documentation and I do when working with me this is what I do every single day work at the mildew baby and when I write code against version 2 . 0 the API i have to go back to the docks a lot and that alone is enough for me to say that we've made a lot of mistakes and it defines of copying pasting from your examples a lot in maybe the the exam maybe the API maybe the wrapper library you have is too verbose and long argument lists are often a a hallmark expression grapple libraries and then if you ever take something out of your API immediately every time you get it turn it into something else that's probably you have a better representation of that data somewhere and so for example in 1 previous version of our API we have emerged field called address and the you can use it's just a datatype it has you know address 1 address to city state postal code you know know the thing and and at 1 point we were actually serving it as 8 2 space-separated string all those fields jam together in our and and so what it nobody in the world needs the data in that format and so you would get it out of the system and then you immediately exploded on those 2 spaces and then her that the thing I actually wanted and so that's 1 of those where you if you just start using it you'll start to pick up on his patterns pretty quickly and
then some things use you can look at for your own API eyes and we use J hyper schema to define the API to finally end points and define how links are served Proteus and it's er currently making its way through the standards bodies it's not a speck yet but I'm hopefully 1 day and we are looking into both swagger and Rommel and we have no immunization yet but hopefully when we launched will want with 1 of those support for 1 of those 2 and if you are using something like Jason hyper skinny you should be able to dock like you should really use that to generate wrapper libraries generate documentation and and 1 really easy way to start finding problems with your uh with the documentation so was documentation with your API is how hard is it to write the the document they are Jennifer order a generator for the documentation and if that becomes really hard and in maybe think about whether this and it's it's hard for you to write a program understand your API how is anybody else and and then make sure you have a ramp represen sample code and in our in version 2 . 0 a sample code are actually so like we have a Rails app I think it's still on version 2 3 years something crazy and we have no doubt would that all that we get apps for all these different languages which 1st of all i so when anybody wants to see right like if Chinese L 2 PPI your Rails app like you wanna see the code that actually interfaces with DAPI and and also that it becomes a nightmare to maintain of and so try to keep a simple code easily copy and paste the ball get rid of as much fluff as you can and you don't need to give people examples as we did on how to build apps just show them how to use your API and and then make sure that you're thinking that catering to different kinds of learners and some people wanna the docks so definitely have docs some people wanna just play with your API and so on so if there's time at the end I can show you the sandbox that we built that auto-updates based engine something but you can browse RE version 3 were API and and then just sort of think about how different the portal on your API and then I know architecture in scaling concerns those are things that you just sort of have to learn the hard way and eventually some use when use your API in a way and the you had anticipated and there would be calling a very expensive call frequently at a high rate and it's going take something down and these at Fiat Figueroa on that but if you know already that you're giving up data that's expensive find a way to catch it find a way to limit access to it find a way to keep it from becoming the default um and you can maybe if try to avoid summers outages so we've got assigned readings correctly you've got maybe 20 minutes left and so it's kind Dixon questions when we have enough time to we can get pretty deep into somebody's so
yeah and so the question is let's talk about authentication and signed
requests a mine out my experience in and knowledge assigned request is much more limited than a basic off and but where I've seen sign request most useful is in and single like if you're using it if you're using your API as a front end as it if you're doing the thing and each doesn't want you which use Rails an API and and put a JavaScript and we see on the front line is saying is that sign requests really help with that aspect and but signed request if you see if you think about the reason why love basic off and for EPI circuit possible is that the amount of time that it takes for a four-year new user to go from i wanna figure out who's on my MailChimp list to I now have a call that demonstrates that like you can do it in 3 lines of code right you you pull pit Peabody or if you're using python you put on request you hit 1 endpoint boom it's done and all those libraries understand each to be basic off at a fundamental level you need to do it in your browser with the you know username @ API key using co whatever's with the at sign before your URL you can you can do that in the browser so HGV basic off if it works for you is amazing because it supported so widely in so many different tools and there are times and places for the things definitely evaluate them all but and if you can support multiple kinds lot that's also good absolutely and that's a great question so in version 3 . 0 of our API we deviated from rest but in in 1 specific place I think and I I don't I'm not entirely sure this is actually deviation of it's just a deviation from what people think of as rest I haven't con gone through the system like figure out but 1 of the things that people tell you about RESTful API that you wanna get burbs out of your under your else bird's eye view the world what that's great and but if you there are some things that are really really weird when you try to turn them into resources so for example we've got e-mail campaigns and and maybe I'm just not as smart as some other people but I couldn't figure out how to get sending a campaign into like a resourceful architecture that made any sort of sense and wasn't overly complicated just for the sake of being RESTful and so we follow her Perot cruise recommendation which is if you have non RESTful actions basically if you have actions that are like BGP verbs if you're doing something other than crowd essentially and to have an action sub resource and then the action after that so in version 3 . over API the 1 and a campaign you go to campaign slash the idea that campaign such actions flesh sending you post that URL and and that's 1 of the biggest places we do that in several places where it just doesn't make sense so like you could have like us sands resource that you then create 1 of them and we thought about that but that to me seems a little contrived and and maybe maybe some of you disagree with that but we thought it was contrived to resort gas and its stop EC but grammar we needed for this so that's 1 example sure so yeah and and if we had that we don't have an right now we don't have a tremendous full of introspection into our delivery side and from the web app side we don't know how many and sent in the web app and delivery knows that we haven't holders API silly but yet that's certainly mean and nothing there are ways to do it and but since you can only send a kinase is maybe a a feature of our of our product you can only send that campaign 1 time ever if you wanna send it again you cloning and create a new 1 in center together so in that way like there would only ever be 1 send request hopefully and we near at that point it's like well all that OK like 1st we just thought it was better to do the the action sense you I haven't actually and Facebook uh API is a scary thing to me and I don't have to touch it every day so I know is there like a specific thing about it that you're curious about what I could maybe it sounds awesome and it sounds really useful it also sound answer yet as so he was about how apparently in the new Facebook graph a real language you can compose different and get different resources relate returned and 1 request and I think almost that that that sort of thing might also be made very easy by something like Web 2 . 0 R H to be 2 . 0 and the 1 that the exact same thing but it might enable it a little more easily send of 3 or 4 requests at the same time get back that sort of thing but yes so that there are so when you're burgeoning your API is there are a couple different schools of thought and 1 of them is and many of these schools of thought are very old people feel very strongly about it and we version are yours and to me that's the easy that's the most straightforward way of another way is to version in your media types and so in your requests are your users would send an except center accepts her would include the version and saying hey were here were ready to accept version 3 . of your API and to me that's a little bit more dense it's a little bit less clear for people and it might be a little more semantically correct and but from 1st from my perspective and sometimes the semantically correct part makes things harder and users and and saying 0 well you're only the give you the example what will inevitably happen if you only version in the header is somebody will write code that doesn't do versioning at all they'll write code against version 2 . 0 of your API you'll upgrade and since they're not passing in accepts version header you get 0 you must want the most recent version and then you'll pass them 3 . 0 break the stuff tho complain on Twitter your boss a B acquired people complaining and water and then obviously ways to avoid that if the don't version use an back but then we surrogate down that radical what will widen when I just have a different point entirely which is what we decided to do and so brokers design guys basically like use rest and end at the the QR code on the top of your handouts there has a link to a whole bunch of different a links that I used in the presentations a Roca's guys on there and some other again as I'm parts as far as we're not use rest right right what to do when you can avoid it I think that an brokers is pretty good and I in a certain sense and that's not really my area of expertise and I I think that at least right now and the the benefits you get from rests in terms of HTTP caching and uh this difference Etienne's ends like Akamai being really easy to work with the view using a RESTful API not being quite so easy to work with the reading x more piece here so I I at and I think they just like with as many people as are using rest Renault were is trying to use rest right now and it's hard to blaze new trails now if somebody did it was amazing then maybe 5 years now will be sitting at about why would you ever use resting anymore nobody uses that and that'll probably happen at some point but I think right now I haven't seen a lot of good and 1 of the reasons why we went RESTful was because we I couldn't find a lot of good reasons to use XML-RPC your so for any of those so sort of all we have to in in almost every case we have a uh we we use of resources so you would go less ID numbers e-mail hash to like find a member and we don't necessarily have a documentation of like oldest member has been sent these campaigns and but we tend to try to make it as hierarchical as possible so that when you down in a member and you can get things about that number and so we try to keep it related that way instead of trying to define a bunch of all this campaign has sent to and so that's maybe a good example of you look at if you get the collection of numbers that have been sent to on a campaign and we intend to provide those Member resources inside of a not inside of the request but if you go to campaign such ideas slash and or maybe it's reports such campaign ID slash of sent to this this yet applicant docs to be out of Accenture but I that will provide you all of a collection of member resources that are the memory resources from this lashless flesh members and point and windows have the heaviest links and them they point back to the canonical representation of themselves back over on lists flesh ID slash whatever so stay answered your question is not really but sort of that's a good idea so documentation show shows sort of like a top-level system architecture diagram of what your resource how your research was will relate to 1 another well let me tell you so OK so I percept tell you are dirty little secret method MailChimp is a PHP up I'm sorry I the but let me tell you how we did to know and so the tell you how we do it in versions prior to point 0 and that is and when you create a new version and you open the directory of the previous version and you select all I bet you know where this is going don't you you copy and then you add the code as appropriate and I don't like that that way of doing it that that is 1 way and we found that cannot be scalable for all the reasons you might think it's scalable in that 0 we found a bug in Version 2 . 0 well I guess we better make the change in 2 . 0 and 1 . 3 and 1 . 2 and in 3 . 0 we've completely change the architecture entirely to support rest at like basically the top the top bottom a couple of all the API whichever 1 is the most basic and and so what we'll do when when we inevitably has version 2 3 . 1 that is we will have our um router at the top will fall back so if if you request version 3 . 0 slash lists and we haven't created a version 3 . 1 of lists it off the router will know to fall back to previous versions of the API and how we will implement that is yet to be determined but we don't have version 4 . 1 but and eventually that is our goal that until a resource actually changes there's no need to version it and and then once we do need diversion save lists does change in 3 . 1 and theoretically many of that much of it will stay the same and so will build to inherit from 1 version 3 . 0 just change what's different and so those are those are some thoughts that we have and moving forward and on what was bad about the way we did 2 . 0 OK so the question was how we do our documentation and how do we make sure the documentation stays up to date with the actual out and will do and all the new in Version 2 . 0 we actually generated this documentation from comments in the code and we also did this crazy thing where our um the API as it was passing the request would check against those Doc blocks using reflection to make sure that your code was your your request was the appropriate so is the right types in whatever that which led to a very interesting conversation I had with co-worker of mine in which 1 of us said all man who broke the API by making a bad comment the rolling up some unit test surrenders comments and if you ever find yourself saying you need test-run comments you have made a wrong turn somewhere and so on so but what we were doing is at the documentation cited + crazy and but you still do end up with a quite the problem of the of of of having to solves my spot of having to keep those kinds of today what we use Jason schema at the renderer level of our API so the 1st thing you do in R version 3 . 0 uh when you're creating a resource is create the schema and the schema will have title and documentation title and description a data type and all this information in the render will use that but to generate the 1 generator and generate a response essentially serve at a deeper level but the the controller the resource returns some data a data object the renderer looks through the scheme and says OK let me pull and this response this and this request needs to respond with the title and it restore a name and e-mail address and whatever else and it goes in polls that data out of the day out of the data object that was returned and constructs the it is serialize it but it builds the serialization for it starts with nothing in ads things from the other darkened of from the other day object a comes back and what that allows us to do is it is it means that unless something is really really bad wrong uh our documentation that is built of adjacent schema will always match the stuff that comes back because the renderers building that exact thing from the scheme in the 1st place and and so we sort of fix that problem by forcing you to design scheme and keep the scheme of today because the schemas what gets returned and and so that's that's sort of our without the that that we had that exact problem words like well we adopted these comments and all this and so we just said no like designed scheme 1st design the code implemented schema later and then it all so far it's been working out pretty well and then we use that to some schema generate documentation right I think swagger actually sometimes you like J. Sun schema to define the resources and so the question was how to how does MailChimp to time the determined White and well what the people are using the resources for and and for this we don't have a very technical approach and because most of the API traffic we get is from those integrations those 3rd parties the baking requests on behalf of 1 of our users on we asked them and and we tried openers lentic indications of that they know that if something is harder confusing that it shouldn't be that they complain to us and that out from the volume of complaints we sort generate that if you keep a lot of stats about your API you can sort of start to intuit things and but I I don't have a technical way I I think that a lot of is just keeping lines of communication open with people that are using your API and listening to them when they say they want something and I don't know if anybody else others like this but I know my 1st reaction to our we need this new features you don't need that features features this is perfect way I wrote the 1st time and as I've to fight that internally and but uh it's really important to do fight that because sometimes when they say I need this that breaks the purity of my API that wall yeah but what is your API that's not useful to people people so so tools to maintain the documentation and OK were 5 minutes over that underlie cut your break and thank you all so much for coming if you have further questions and please come see me the size of a of his own and the moons and in some
Subtraktion
Prozess <Physik>
Momentenproblem
Versionsverwaltung
Interaktives Fernsehen
Implementierung
Sondierung
Code
Eins
Magnettrommelspeicher
Last
Software
Uniforme Struktur
Inhalt <Mathematik>
Optimierung
E-Mail
Regulator <Mathematik>
Softwareentwickler
Betafunktion
Gebäude <Mathematik>
Einfache Genauigkeit
Computervirus
Fokalpunkt
Quick-Sort
Mapping <Computergraphik>
Randwert
Software
Dienst <Informatik>
Generator <Informatik>
Ablöseblase
Codierung
Bitrate
Innerer Punkt
Quelle <Physik>
Randwert
Natürliche Zahl
Klasse <Mathematik>
Formale Sprache
Web-Applikation
Versionsverwaltung
Geräusch
Term
Weg <Topologie>
Web Services
Objektorientierte Programmiersprache
Front-End <Software>
Vorlesung/Konferenz
MIDI <Musikelektronik>
Softwareentwickler
Web Services
Inklusion <Mathematik>
Softwareentwickler
Transinformation
p-Block
Physikalisches System
Objektklasse
Fokalpunkt
Quick-Sort
Randwert
Software
p-Block
Innerer Punkt
Brennen <Datenverarbeitung>
Bit
Gewicht <Mathematik>
Momentenproblem
Versionsverwaltung
E-Mail
Bildschirmfenster
Wrapper <Programmierung>
Informationsmodellierung
Reelle Zahl
Wrapper <Programmierung>
Programmbibliothek
Kontrollstruktur
Vorlesung/Konferenz
Datenstruktur
Softwareentwickler
E-Mail
Beobachtungsstudie
ATM
Ontologie <Wissensverarbeitung>
Zwei
Güte der Anpassung
Cliquenweite
Systemaufruf
Schlussregel
Physikalisches System
Biprodukt
Fokalpunkt
Ereignishorizont
Quick-Sort
Entscheidungstheorie
Rechenschieber
Arithmetisches Mittel
Dienst <Informatik>
Innerer Punkt
Zeichenkette
App <Programm>
Telekommunikation
Subtraktion
Wasserdampftafel
Versionsverwaltung
Mailing-Liste
Quick-Sort
Übergang
Konfiguration <Informatik>
Mailing-Liste
Datenmanagement
Web Services
Verkehrsinformation
Mustersprache
Verkehrsinformation
Bit
Hochdruck
Gruppenkeim
Versionsverwaltung
Datenmanagement
Statistische Hypothese
Web-Seite
Statistische Hypothese
Computeranimation
Internetworking
Übergang
Mailing-Liste
Datenmanagement
Gruppentheorie
Verkehrsinformation
Mixed Reality
Speicher <Informatik>
E-Mail
Schreib-Lese-Kopf
App <Programm>
Statistik
Datennetz
Benutzerschnittstellenverwaltungssystem
Kategorie <Mathematik>
Gebäude <Mathematik>
Stellenring
Mailing-Liste
Quick-Sort
Texteditor
Datenfeld
Körper <Physik>
Menge
Offene Menge
Rechter Winkel
Benutzerschnittstellenverwaltungssystem
Mereologie
Dreiecksfreier Graph
Identifizierbarkeit
Wärmeausdehnung
Information
Ultraviolett-Photoelektronenspektroskopie
Kantenfärbung
Innerer Punkt
Lesen <Datenverarbeitung>
Standardabweichung
NP-hartes Problem
Parametersystem
Zentrische Streckung
Web Site
Punkt
Diskretes System
Gruppenkeim
Mailing-Liste
Störungstheorie
Kontextbezogenes System
Homepage
Hydrostatik
Datenfeld
Menge
Rechter Winkel
Parametersystem
Randomisierung
Inverser Limes
Wort <Informatik>
Spezifisches Volumen
Schlüsselverwaltung
Innerer Punkt
Videospiel
Softwareentwickler
Umsetzung <Informatik>
Subtraktion
Quader
Antwortfunktion
Systemaufruf
Abfrage
Mailing-Liste
Inverser Limes
Rechter Winkel
Softwareentwickler
E-Mail
Message-Passing
Varietät <Mathematik>
Touchscreen
Teilmenge
Arithmetisches Mittel
Sichtenkonzept
Konditionszahl
Besprechung/Interview
Versionsverwaltung
Binärcode
Default
Übergang
Datentyp
Decodierung
Rechter Winkel
Endogene Variable
Rechenschieber
Content <Internet>
Systemaufruf
Dicke
Softwareentwickler
Code
Computeranimation
Endogene Variable
Web Site
App <Programm>
Browser
t-Test
Statistische Hypothese
Code
Statistische Hypothese
Computeranimation
Homepage
Deskriptive Statistik
Textur-Mapping
Client
Benutzerbeteiligung
Bildschirmmaske
Standardabweichung
Notebook-Computer
Endogene Variable
E-Mail
Leistung <Physik>
App <Programm>
Transinformation
Architektur <Informatik>
Datennetz
Mobiles Internet
Systemaufruf
Mailing-Liste
Quick-Sort
Arithmetisches Mittel
Beweistheorie
Codierung
Beweistheorie
Standardabweichung
Schnittstelle
Nebenbedingung
Server
Punkt
Applet
Nebenbedingung
Implementierung
Patch <Software>
Code
Physikalisches System
Informationsmodellierung
Code
Endogene Variable
Uniforme Struktur
Zusammenhängender Graph
Schnittstelle
Caching
Fehlermeldung
Datenmodell
Systemaufruf
p-Block
Physikalisches System
Flächeninhalt
Mereologie
Client
Codierung
Server
Identifizierbarkeit
Speicherabzug
Fehlermeldung
Standardabweichung
Ebene
Web Site
Subtraktion
Punkt
Kontrollstruktur
Adressraum
Selbstrepräsentation
Formale Sprache
Versionsverwaltung
Kartesische Koordinaten
Computeranimation
Homepage
Hypermedia
Message-Passing
Benutzerbeteiligung
Lesezeichen <Internet>
Adressraum
Minimum
Endogene Variable
Datentyp
Translation <Mathematik>
Dateiverwaltung
COM
Wurzel <Mathematik>
Auswahlaxiom
Nichtlinearer Operator
REST <Informatik>
Datenmodell
Einfache Genauigkeit
Mailing-Liste
Nummerung
Binder <Informatik>
Elektronische Publikation
Quick-Sort
Datenfeld
Rechter Winkel
Hypertext
Mereologie
Hypermedia
Gamecontroller
Hill-Differentialgleichung
Ordnung <Mathematik>
CMM <Software Engineering>
Message-Passing
Aggregatzustand
SCI <Informatik>
Subtraktion
Punkt
Wasserdampftafel
Versionsverwaltung
Gruppenkeim
Datenmanagement
Implementierung
E-Mail
Statistische Hypothese
Code
Homepage
Hydrostatik
Mailing-Liste
Datenmanagement
Skalierbarkeit
Gruppentheorie
Statistische Analyse
Softwareentwickler
Ganze Funktion
Schreib-Lese-Kopf
Lineares Funktional
Transinformation
Benutzerschnittstellenverwaltungssystem
Pay-TV
Abfrage
Systemaufruf
Routing
Mailing-Liste
Quick-Sort
Konfiguration <Informatik>
Teilmenge
Datenfeld
Menge
Rechter Winkel
Stapelverarbeitung
Ordnung <Mathematik>
Verkehrsinformation
Fehlermeldung
Parametersystem
Punkt
Datenmanagement
Ruhmasse
Implementierung
Mailing-Liste
Quick-Sort
REST <Informatik>
Homepage
Mapping <Computergraphik>
Mailing-Liste
Font
Körper <Physik>
Gruppentheorie
Vorlesung/Konferenz
Punkt
Browser
Adressraum
Selbstrepräsentation
Formale Sprache
Versionsverwaltung
Sondierung
Raum-Zeit
Arithmetischer Ausdruck
Web Services
Unordnung
Mustersprache
Default
Parametersystem
App <Programm>
Güte der Anpassung
Abfrage
Ruhmasse
Systemaufruf
Bitrate
Kontextbezogenes System
Datenfeld
Dateiformat
Information
Ordnung <Mathematik>
Standardabweichung
Fehlermeldung
Aggregatzustand
Zeichenkette
Lesen <Datenverarbeitung>
Rückkopplung
Subtraktion
Hypercube
Thumbnail
Code
Weg <Topologie>
Massestrom
Stichprobenumfang
Wrapper <Programmierung>
Datentyp
Programmbibliothek
Elastische Deformation
Spezifisches Volumen
Optimierung
Transinformation
Gerichtete Menge
Green-Funktion
Thumbnail
Einfache Genauigkeit
Mailing-Liste
Schlussregel
Physikalisches System
Binder <Informatik>
Quick-Sort
Schlussregel
Rückkopplung
Hypermedia
Computerarchitektur
Innerer Punkt
Bit
Umsetzung <Informatik>
Komponententest
Punkt
Spiegelung <Mathematik>
Browser
Adressraum
Web-Applikation
Selbstrepräsentation
Formale Sprache
Versionsverwaltung
Formale Grammatik
Schreiben <Datenverarbeitung>
Kartesische Koordinaten
Computeranimation
Übergang
Deskriptive Statistik
Skalierbarkeit
Vorzeichen <Mathematik>
RFID
Bildschirmfenster
Minimum
Volumenvisualisierung
Kontrollstruktur
Router
E-Mail
Figurierte Zahl
Gerade
Metropolitan area network
Serviceorientierte Architektur
Sichtenkonzept
REST <Informatik>
Güte der Anpassung
Systemaufruf
Nummerung
p-Block
Biprodukt
Generator <Informatik>
Twitter <Softwareplattform>
COM
Benutzerschnittstellenverwaltungssystem
Rechter Winkel
Festspeicher
QR-Code
Information
URL
Verzeichnisdienst
Lesen <Datenverarbeitung>
Standardabweichung
Telekommunikation
Subtraktion
Facebook
Wasserdampftafel
Baum <Mathematik>
Mathematisierung
Gruppenoperation
Zahlenbereich
Kombinatorische Gruppentheorie
Term
Code
Data Mining
Multiplikation
Benutzerbeteiligung
Perspektive
Hash-Algorithmus
Endogene Variable
Datentyp
Programmbibliothek
Spezifisches Volumen
Indexberechnung
Graph
Statistische Analyse
Mailing-Liste
Automatische Differentiation
Physikalisches System
Binder <Informatik>
Quick-Sort
Integral
Programmfehler
Objekt <Kategorie>
Diagramm
Flächeninhalt
Offene Menge
Caching
Debugging
Hypermedia
Digitaltechnik
Mereologie
Gamecontroller
Authentifikation
Wort <Informatik>
Serielle Schnittstelle
Computerarchitektur
Verkehrsinformation

Metadaten

Formale Metadaten

Titel Do Users Love Your API? Developer-focused API Design
Serientitel RailsConf 2015
Teil 03
Anzahl der Teile 94
Autor Holiday, Pete
Harlan, Kate
Ranson, Nate
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/30659
Herausgeber Confreaks, LLC
Erscheinungsjahr 2015
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Do Users Love Your API? Developer-focused API Design

Ähnliche Filme

Loading...