 Okay, they're closing the doors, so I think that's my prompt to begin. Hi, thanks for coming. Have you all had a wonderful lunch? Are you all feeling kind of warm and sleepy now in this room with no natural daylight? The talk is made up of a few different sections. I'm not at all offended if you nod off, but please try not to snore. It puts off the people around you. Okay, so hi, my name's Lorna. I'm a developer advocate for IBM working mostly with their cloud database systems. That's not really my background. I'm a PHP developer. I just have a new job now. So I am delighted to have managed to join those things up and find a reason to come to Drupalcon and to talk to all of you. So why have I chosen to speak about HTTP today? HTTP wires the web together. It's a lot of the time we don't think deeply about it. We can go a long way without knowing an enormous amount about the theory, but it is very important. And I think as we move more to making modular systems that talk to each other, as we move more to using Drupal perhaps as an API backend and setting that content out to some other thing that isn't a front end of Drupal, it's increasingly important that we really understand HTTP. And this will help us to choose and design solutions as the expert crafts people that we are, but also to understand what's going on when things go wrong, debug systems more effectively, basically get stuff done. So that's my aim is to give you some things that you can use to get stuff done. I'm going to cover a little bit of HTTP theory to kick off with, probably familiar to some people, maybe not to others. I'm going to talk a bit about the tools that I use when I work with HTTP. I'm also going to cover OAuth because I think it's a nice sort of show piece of what you can do with HTTP. I also think it's quite a common use case. So it's likely that it's something that you'll come up against. So the first thing I want to tell you about HTTP is HTTP is an envelope format. Think of an envelope that arrives through the post. There's information on the outside as well as information on the inside. On the outside, there's the address, the postmark, a stamp, maybe a return address, maybe do not open until your birthday. Some other information might go on the outside. And on the inside is the letter, the birthday card, hopefully with a check in it that you were hoping for. HTTP is really like that. The stuff we see in the browser is what's on the inside. But all the headers and the metadata is the stuff that's on the outside. That means that we can transmit this data safely from one place to another and also that we know how to understand it when it gets there. I'd like to show you some examples of requests and responses. So this is a straightforward HTTP request. I've pointed it on my own blog, LawnanJane.net, so that I don't incriminate anyone else. Look at the first line, it's a get request to slash. Look at the second line, we're making that request to LawnanJane.net. Look at the third line, this is curl. And look at the fourth line, accept star slash star. Curl thinks it understands every possible content type on the planet. Diplomatically, I'm going to say curl's an optimist. Curl is lying. The response headers that come back from that request look like this. I've got a 200 OK. This is good. I have a list of status codes for you in a moment. There's a date, so you can tell how long ago I wrote this in order to do a dry run with my local years group. A content type, my website says, is text HTML. There's some gooky stuff here, cache control, references to other links. More caching header and an expires header. So that's the HTTP response. We don't see this stuff when you make a request to LawnanJane.net. You get like a picture of an angel and some blurb where I probably wrote by myself in a third person and then some blog underneath that. But the headers that come back look like this and they give us all the information that we need to understand the body payload that was returned. This was a straightforward get request and we can use lots of different types of verbs. Verbs, when you're at school, you learn they are a doing word. They indicate which action is taking place, right? Sometimes the things we learn in school don't seem very useful, but this one is quite transferrable because it applies to HTTP as well. It's a doing word. So when we do a get request, we literally fetch it. That's safe, you can repeat it as many times as you like and you should always get something back. A post request, we would normally send some data along with the request. So the request will have the headers that you've just seen and we'll probably send a body as well and the response will come back and it will probably have a body as well. The big difference between get and post, we can use either of them when we're filling in forms or sending requests by other means, the get request, you see the query parameters on the URL. This is intentional. You use get when you should be able to bookmark it, that you should be able to safely repeat this request. This is why we see the get parameters used when it's a search result. So you fill in a complicated search form, you might want to bookmark that or share the link with someone. It's always safe to repeat the search. A classic example of post might be a user registration form. Once I've registered you, I don't want you to do that again. We send it as post, it's not safe to repeat that and that's why your browser always asks you, are you sure when you try and repeat a post request? Because typically that's not what it's intended for. So you can make a decision about how you submit your forms. Working with APIs, exactly the same thing as applies. We use get to fetch data, we use post usually to create data. I've got delete here. Guess what that does? I could explain it to you clearly and slowly and then you really will go to sleep. We've got put. We normally use put to update data. So you would do get, look what you got, change it and then put to a put back to do an update. There's also patch which we use in APIs for updating and in that case you would just supply the piece that you want to change. GitHub has an example of this. It uses patch rather than put. The specs are finalised in patch but it's live and well on the internet. There are various different types of headers. There are request headers. You've seen the host header, the accept header. There are response headers. Come back and tell you about the metadata that belongs with the response. So we might have an e tag which is gives like a hash of the content which we can use for caching to know if something's changed. You might get a location header which would then cause your client to redirect in most cases. We also get entity headers. These can be included with either request or response. It's with anything that has a body. So if we're posting data, there'll be a content type in the request because there's a body in the request. And when it comes back in the response we'll have content type there as well. So request headers, response headers and entity headers, meaning headers that belong with some kind of body or payload. When we get a response, we get status codes. So we'll always get some kind of headline news. It's like the pass or fail red or green response and then you can burrow on down into the body and understand a bit more about what happened. I've tried to include some of the most common ones on the next couple of slides, things that I think you're likely to see. So 200 okay is all good. You'll also see a couple of other statuses that start with a two. They are all so good news but they're more specific than just a yes. The 201 indicates that a record is created and sometimes you'll get 204 which means the request that you've sent has been successful but I don't have anything to send back. So for example, if I send an HTTP request with a delete verb the record gets successfully deleted. Good, but what are you going to send back to me? Not the record, it's not there anymore. There's no information to return. The 204 is helpful because it means that we don't need to check the body. We're just like yep, good. You commonly see 302 found. I think Drupal outputs this. I don't do any Drupal so don't ask me any Drupal questions. I think Drupal outputs this is normally because it's a result of a rewrite. So yes, I found the content. There was I followed some rewrites to get there. So 302 is as good as a 200. A lot of frameworks will return a 302 because technically they should. And sometimes you get 302, 307, which is moved temporarily. You can do this if for some reason you have, it's usually in the middle of site migration. You have URLs which are temporarily pointed to a different endpoint, but that's not going to be their eventual home. Use the 307 and the search engines won't update their references. They'll keep using the original URL. So this is going to be quite helpful if you're in the middle of a migration. For status codes where things are not going so well, these are the ones that start with a four or start with a five. If they start with a four, it's the user's fault. And if they start with a five, it's the server's fault. Okay, like my fault, your fault. That's how it works. The 400 is just an umbrella, bad request. You see it a lot in APIs and there'll be more information in the body. I've put 401 and 403 here. They sound quite similar, but they're crucially not. Right, so let me give you this tip. 401 means unauthorised. I don't know who you are. Please identify yourself. And that's where you'll often get, like if it's a basic auth, you'll get that unbranded pop-up and you need to supply some credentials. 403 forbidden. I know exactly who you are and you cannot come in, right? So 403, I am confident that you do not have access. And 401 is we need to verify who you are before you can have access. So there's two sort of auth-related errors, but they genuinely mean different things. I'm guessing you're familiar with 404 not found. I requested me to the server for a resource which is not found. 500, server error. This is a bit of an umbrella term as well. And a lot of the time we pass a request to Apache, Apache hands off to PHP. PHP drops off a cliff. Apache kind of comes back to us going. So a 500 is not a very descriptive error. We see it because often the thing responding to us doesn't have any more information than this. So PHP can have segfalted or something else catastrophic has happened which has meant that it doesn't have any more information to tell us. So that happens. Something else that we see which I think is important to understand is cookies and sessions. So we don't often work with cookies, you can, you probably will at times. But in PHP we typically work extensively with sessions. And what that means is rather than putting information in a cookie and storing it on the user's browser, we store it on the server. Every time a new user visits our website, not when they log in, just when they arrive, we generate a new unique identifier, it's called the session ID, and we send it to them in a cookie. And by convention, their browser will always send back that same cookie with that same session ID in it. And we use it to identify them. We keep a store on the server by default PHP writes to files which is fine if you're on one with a web server. Once you outgrow that, put it in reddus, it performs really well. And we write information related to this user or this user's session into local storage on the server. So the user can't see this, they can't tinker with it, but we can do it. It works using the cookie. And I'm going to show you an example of how to fiddle your cookies in a minute. So one thing we can do with headers is negotiate content types. So for applications that can speak more than just HTML, then we can do content negotiation. So we send an accept header, which says, I would like this and I accept the following formats. Like I only speak JSON. Then the server should look at what the accept header choices were, which formats it supports, and then try and work out some good combination of those two. Try and send you back something that you can understand. So this is the accept header that my browser is sending by default. I'm using Chrome. Imagine that this is split on commas. So it's comma separated. Some of those values also have a semicolon and a Q value. The Q is how preferred things are. So anything which doesn't have a Q value is Q equals one. Like I really want this one and the others are less preferred. So I want to just show you this in action. I'm not crazy enough to demo live. So it comes to you in screenshot form, screenshot, screencast form. Okay, press this button, this button. I have a new operating system and it's not totally on my side. So what you are looking at here is, I'm not sure if you can read the fonts, but hopefully you can at least tell the difference between rendered HTML and JSON, which will happen in a minute. What you're looking at here is the output of my local development platform for joined in. So api.join.in would be the live version. It's, the root of an API is a list of hyperlinks. This API speaks both HTML and JSON. I'm using Chrome. So, first of all, we use the developer tools and I want to just show you around my Chrome developer tools. If you're not a Chrome user, don't worry. Safari, Firefox, Internet Explorer, all have the same sorts of things. I just happen to be a Chrome user and I like it. When I refresh this page, I get a list in the network tab, I get a list of all of the web requests that were made and some information about them. The bottom three quarters are my Chrome plugins. The top one is the API request I actually made and the second one is the fav icon. So there's a lot of stuff going on in here. We're really only interested in the top one. You can't read the font, but it says it hit api.dev.join.in where the response status was 200. It's a document and it tells you where it came from and how long it took and you get like a waterfall diagram. This can be really interesting because if you've got a PC or website that didn't load, you'll see the Ajax call here or you'll see the asset that was supposed to load and didn't and you'll see the 404 or you'll see that something happened. You can also click on it in the left hand column and get a bit more information about it. So when you click on this, you can see the request headers and the response headers and everything that was sent. You can also click on the response tab and see everything that came back. So sometimes you'll get some JSON which your client-side JavaScript can't pass. And if you come in, it looks like a 200 okay, there's no problem, but it's just fundamentally not working. Maybe you're seeing errors in your JavaScript console. Come here and in the response, you may find an HTML error message page where your JavaScript or well-formatted JSON should be and your client-side JavaScript just won't be able to de-json it because it's invalid. That happens a lot. Here you can see that request header that I mentioned earlier. I'm sending text HTML. Another thing that you can do here which I think is really valuable is copy as curl. What request did this make? How can I replicate it? Copy as curl. Curl is command line tool that makes web requests. Click the copy as curl, paste it at the command line. This, I'm really happy that you can't read it. It's really a horrendous mess, but it does perfectly replicate the request that was made. All the headers, all the compression headers, the cookie, everything. This is a perfect repeat of the request that maybe you had a problem with. And you can come here and see like, oh, what happens if I don't send the cookie? Oh, what happens if I change this, change my user agent, change my accept header? So you can play with it here. This is a really nice quick start for, I'm going to paste this into curl and now I'm going to debug it. I make the request and hopefully you can sort of see there's a bit of CSS, a bit of HTML. That's all that happens there. Back in my browser, I'm going to ask for application JSON. This plugin, it's a little blue circle with like a Apple command button symbol and it is called mod header. It allows me to override the headers that my browser would ordinarily send. So I'm just going to send application JSON from my browser. When I make the request, I'm just going to refresh the page. Suddenly I get JSON back. And again, I can inspect through my headers. You can see that's the accept header I sent application JSON. And using those tools, I can just switch it. So that's content negotiation, changing my accept header. Because I'm showing you some Chrome stuff, going to show you some other Chrome stuff while I'm on it. This is the web front end. Again, still on my dev platform. So I've got auto-generated nonsense data. Everyone should have hilarious sample data generators in their project. It's the most fun ever. So again, this is my local copy. All I'm going to do here is login with the standard kind of stock password. Her password is password. We log in. You can see I'm logged in. Her name appears. This plugin is called Edit This Cookie. Again, equivalents exist for all the other browsers. Edit this cookie. And I'm going to delete the cookies just for this website. So when you get the advice, you need to clear your cookies and close your browser. And it logs you out of every application you've ever used. Don't do that. Do this. Just clear the cookies for the site with the problem. Don't log yourself out of everything else on the internet ever. So you can come here. You can create cookies. You can edit your cookies. You can do your light with your cookies. I've just deleted them all because it's a nice quick demo. When I refresh this page, I'm not logged in anymore. And that's because I lost my session cookie. So I log in. I give my session cookie. Well, oh, she's logged in. We store it in the session. Request comes in. It's got the cookie. Good. We know who you are. We put your username in. We send it back. Once I delete that cookie, I'm not logged in anymore. So this can be quite helpful if you are testing with login and stuff. Or if you do get into any kind of cookie related problems. Okay. Back in the slide deck. So the tools I've just used. One header. Edit this cookie to Chrome plugins. Equivalence exists. These slides are already online. I didn't link them from anywhere good though. So you'll have to hunt really hard to find them. Or wait for me to tweet. All right. I'm Lana Jane on speaker deck. You can find them now. The open source project here is joined in. Not widely used in the Drupal community. Massively widely used in the PHP community. It's for giving public immediate feedback to speakers at events in case you're wondering what you're looking at. Okay. I use HTTP on a day to day basis. I am not a web developer. I've actually never really been a web developer. I'm allergic to pretty. So I've done quite a lot even when I was a PHP developer I mostly did APIs. And now I'm a database developer. I mostly work with a tool called CouchDB which has an HTTP web interface. So I tell you this is not a talk about CouchDB because I'm going to show you it in my demo. Let me just tell you CouchDB has an HTTP interface. That is how you talk to it. You just make web requests. It's very restful. So there's get and put and post and delete. It's an open source project. It's there. It's a document database. So it doesn't have rows and columns. It doesn't have a schema. You don't decide up front what shape your data should be. You just put things in collections. And it speaks JSON over HTTP. Also has awesome replication in sync. I went to a talk yesterday about the workflow initiative and when you start replicating between sites it will use either this or an implementation of this protocol. So CouchDB interesting. You'll probably hear it mentioned a few times. So let me show you some of the way that I work with HTTP. Also in a pre-canned video. Press this, this and this. There we go. So you saw Curl briefly earlier. I'm making a Curl request to local host. 5984 is the standard port for CouchDB. I make a get request. It talks back to me and says, hello, I am Couch. There's a bunch of things that we can do with Curl. Here I'm creating a database. It's a port request. So use dash x to specify the verb that I want to use and I'm creating a products database. That exists now. I got an okay true. If I was inspecting the headers as well you'd see a 201 created because we made something. Sending the Curl request. I can see a list of databases by hitting this endpoint. You see there's a couple of internal ones. There's my products DB that I just created showing up here. There's all very much on the command line. You can do everything you could ever imagine and some things that you will never need to imagine with Curl on the command line. Here I'm setting a header. That dash h is setting a header just setting the content type because I'm making a post request. I'm going to create an item in my products database. So making a post request to the products database writing some very short JSON because this gets really boring to watch me type. Thankfully you're not watching me really type it. Again we'd have got 201 created. It creates the record. It gives me back just a JSON string there. Couch DB has an ID and a concept of revisions. So you'll see both of those everywhere when you're working with Couch DB. Now I've put a product into the database. I can again make a get request which is the default to the products and see that my doc count is one. That's like the second thing along there. It's not very pretty to read. So this piping it to JQ. JQ is command line tool for dealing with JSON. This is really helpful for all kinds of working with JSON but I use it when tools give me back something that looks like that because I would rather read it looking something like this. So if you are working with JSON on a command line, working with APIs, try like, I think curl is a key skill. It's not the world's friendliest tool ever but it's probably installed on your server which is the big plus point. It's fairly ubiquitous. But JQ is super cool for giving you back in a formatted readable for a normal person, sort of a way. I started using another tool recently called HTTP console. This is just an NPM install. HTTP console put in your base URL and then you can start just, it's a bit more of a humane syntax, making a get request for that list of databases and it shows you some of the headers and nicely formatted JSON data. The person recording this video is like happily still typing away and I'm still talking. So getting all those DBs, this is the list of databases. I can set the content type and that gets stored as a header in HTTP console. It'll be used for all future requests. So you can just set it and it'll stick. This is cool because you can set cookie values and stuff and it just sticks and means it keeps on working. Dot headers shows I'm always sending accept star slash star. I'm going to hit local host and I'm going to send my content type application JSON. Creating a product, I'm going to make a post request to products and then it stops to let me type my data. Again, I'm typing something really short here. We've got a bag, I've got shoes. There's the response. So a little bit more humane to work with, I think, than curl. Everything you want to do in terms of verbs, headers, data, it's all here. It's a little bit more usable than curl. And I'm finding it really quite nice to work with, which is why I'm mentioning it to you here. There's the products collection again, nicely formatted. Okay. This is postman. This is how you make web requests for normal people. I am a command line nut partly because I have some disabilities so I find it difficult to use a mouse. Graphical tools are hard. So if you ask me to debug your API problem, I am going to use curl. For normal people, and I include you in that broad definition, I want you to try this tool, postman. There's a bunch of options. So try loads of tools until you find one you like. But get to know your tools really well because you probably mostly need them under pressure. So try and have a play on a rainy afternoon when you're not under pressure and get the skills that you need. So this is postman and we're going to do the same thing again so that you can see it in all these different ways. So I get request to all DBs, press send, get the JSON response back. I'll post request to create another product in the database. So we're posting into the products collection. I need to set the header because I'm going to send some JSON content. The server doesn't understand me unless I say, this is JSON, then it will JSON decode it. Couch only speaks JSON so it could make assumptions, but it doesn't. Again, type, send, here it comes. And if you scroll down, you can just see that 201 created in the bottom right hand corner. And again, I get that response back. So the point here isn't CouchDB at all, but trying to show you how the same operations look in a bunch of different tools and it's for you to find something that works for your tool preferences. Quite a few of the IDEs have some of this sort of tool built in. Postman is cross-platform, use it wherever you like. It was a Chrome application originally, but also comes standalone now. If you're on a Mac, try pause, like cat pause, pause. That's supposed to be really good as well so that can be an awesome tool to work with. Okay, where was I? So, links to all the tools. Obviously, I'm going to tweak the slides, so I don't feel that you need to grab them all. You saw Curl, first of all. It's been around forever and does everything. HTTP console, I like it. And it's super easy to install with NPM. I find it a little bit easier to use. JQ is my JSON handling magic tool. Yes, I'm getting some support from the second row here. JQ is awesome. If you do work with JSON, you haven't found it. It's a real time saver. And then get Postman for the Postman tool, the more gooey approach. And the nice thing about Postman is you set it all up and you set your headers and your body and whatever and you send the request and then you can just make a few more changes and send it again. It's quite easy to just kind of edit. You didn't see it in the video because I tried to zoom up my font size as much as I could. I'm not sure how well that worked. But it also has a sidebar that you can pop open with the history of what you've done. So if you do like a how can I list, make a web request to an API endpoint that lists things and then you create some stuff, it's easy to go back and click on the request you made before and repeat that one and sort of see what's going on. So it's very friendly, very usable. Okay, let's talk about authorization because I think this is quite a common or I think it's really important. I also think it's something that you're likely to come up against that uses a bunch of the stuff that I've talked about today. So we talked about HTTP being an envelope format. So the metadata is in the header and the real content is in the body. And what you'll often see is that the authorization, which is not really part of the product or content or whatever it is that we're transferring as the body of our request, the authorization is not really part of the content. So we shouldn't be making requests that send usernames and passwords anywhere other than in the header. So normally we'll do identification authorization in the header of HTTP. That's typically considered to be good design. Even better than sending the username and password is to use a token. I have simply written tokens are ace. They're ace because they're very flexible. So we use a token instead of a username and password. So instead of supplying your credentials we instead arrange for whichever app is doing the access to have a token and that token first of all I can tell it's the token being used rather than actually you logging in. So we've already got this distinction between you personally and something on your behalf. It can also be restricted in some way. So for example we might only grant read only access. The token might only be valid for a certain amount of time. It might not have access to everything. When you sign up for an access token with github you have to put scopes you want. So you're making like a super cool to do list thing that uses gists as its storage. There's an app that does that. You can give the app access just to your gists and they won't write all over your repose or manage your organisation privileges or all the other things you can do off the app. So the tokens can be restricted in lots of different ways. They're very flexible. Crucially they also mean that let's say you download something onto your phone and it goes rogue and starts posting to github or posting to your Twitter stream and there's no way of it hasn't got a log out button and you uninstall the app and their server is still posting to your thing. You can go to github and delete the token there. So the tokens are really it's a nice way and if something happens your token gets intercepted on the wire or something just revoke it. You don't need to change your password and then my Twitter account is authorised against a bunch of different things. I have a lot of devices I sign in with Twitter in a lot of places. I use tools like Buffer to schedule my tweets. If it all used my username and password and I changed my password it would take weeks to get everything logged back in again. Whereas with a token you can just stop the one token from working and not affect everything else that's going on. For simple authorisation you may see Basic or DigestOrth and that is basically an authorisation header with Basic or Digest and then some kind of hash. For Basic it's just username, password and it's Basic 64 encoded for Digest is a bit more complicated but not much. So you're basically sending content in the clear here be careful and if you're going to use BasicOrth probably use DigestOrth yeah. A really common standard and particularly related to the tokens idea that I was just talking about is Oorth. Now you may have used Oorth 1 hoping that not many of you have was a bit of a pain. If you have try and forget the experience completely Oorth 2 is way better. Oorth is designed to kind of acknowledge the fact that we can do better than just having applications log in as you which is how things used to work. So it acknowledges that there's a user, that's you the provider so something you already have an account with maybe it's GitHub or Twitter, Facebook I think Drupal.org is also an Oorth provider somebody who writes a site that integrates with it so tell me. Anyway so something that already has your data and then there's a consumer which is some kind of third party so you're going to allow like you want to use a GitHub client on your phone so you're going to let this third party client have access to your GitHub account so it really acknowledges three players in the relationship. Crucially important before we proceed you will do this over SSL Oorth 1 was really hard to work with because it needed a PHP extension and it did encryption and there was a nonsense nonsense for nonsense and fundamentally it quite frequently didn't work and was really hard to debug. Oorth 2 just did away with all that nonsense security stuff that used to make it hard to use and we just send credentials on the header which is great but it means you must must must do Oorth over SSL because you are you are literally sending an access token over the wire in the header so you know we have security we have SSL we've already invented this let's encryptors come along there are no excuses so you will do it over SSL and you will even do it over SSL on your test and staging environments I won't chase you down about your dev environments Oorth has a bunch of different ways of doing what it calls grants so a grant is like permission to get access permission to get an access token there's a bunch of ways you can do this the most common way is the authorization code and you have seen this you go to a new website you choose to sign in with twitter right so you click the sign in with twitter button you end up on twitter if necessary you log in and it says blah blah blah this app would like access to your account and it will be read only or read write or read write and DM I think of the twitter levels so you get information about what's going on and you either authorise or deny if you authorise you get forwarded back to where you came from and what's actually happened although you don't usually see it is that a little authorization code has been sent back with you as you went back to the consumer's website and that authorization code becomes the grant the consumer that you are trying to you are trying to log into using twitter as an authentication source uses that to exchange for an access token so that becomes the grant alternatively you can have the implicit grant where you go to this is client side applications because we can't hide anything on the server right it's already in the client and the way that this is less secure but client side implementations do it and so it's appropriate in some cases where instead of sending you back an authorization code that gets exchanged for an access token you just go and say yes and you get forwarded back with the access token so it's visible another type of grant that's in my demo in a moment is the password let's say well the real example is the open source project that you've just seen is an API it also has the web front end that I showed you that I logged into and logged out of and it talks to the API I obviously, well my team I'm project maintainer we built both of those right when you log into our web front end I can't send you to the API to agree for an access token this makes no sense so where there's a lot of trust and the thing consuming the OAuth you can do the password grant and basically people come to the website they give their username and password and that allows us to exchange for an access token so they log in with their username and password that's only if it's the same like I wouldn't allow another consumer other than the project own website and own apps to use that grant everybody else has to do the authorization code and come in send their users to our web front end get them to confirm it then they go back and get a code there's also some situations where the client credentials client credentials you just give a client a hard coded access token and this will be something like your reporting tool or something like that which is just you just need some access it's not really attached to a user usually so with all these various ways of getting a grant type then log in and get an access token and then use that access token this way, this way I'm hoping that by the end of conference season I've given 15 talks I'll have worked out how my data works this button, this button here we are right, so here is a curl command that was too long winded to type so I just stuck it on the screen before I started the video I'm making a post request I'm creating something in this case I'm creating a token now I make a post request it's got a content type header application JSON because I'm sending some body data and I'm hitting the token end point because I'm making a token and I'm sending some data and my data is the grant type password the user's actual credentials and the client ID and secret this is test data so this does not work on my live platform seriously someone asked me that the other day and I was like no this is not this is not active on the live platform does work on the test platform we scramble the database and inject some extra client registration so that all of our API tests work so I'm creating a new token I'm using the password grant type which means that I'm going to get an access token in response press go there's the access token and it also tells me which user I'm logged in as so I grab that access token and I can go ahead and use it and I'm going to send it with every request if I just make a request without it it's not very readable hopefully I'm going to point a post it through jq now there we go make a request without it I just get that list of links that you saw before add it authorization bearer paste the access token send the request you can see that I get the extra metadata so I'm logged in now the access token means that I'm logged in and it makes the API respond to me as a logged in user so it can show me things like which are my talks which events I'm going to which people I'm friends with so the data starts to respond to me in a way that's related to how I'm logged in and you can see how what we've already done with talking about HTTP and talking about sending headers plays in here sending that authorization header along the way I can still use the access token as well in the browser this is something that I use mod header for a lot this API has a has the HTML renderer and so I can just plug in my access token or plug in a cookie that I want to send and do it each time and you can see there I sent the access token and it knows who I am so the OAuth working with the access token is I think a nice use case of HTTP and something that I expect that you might come across as you integrate with third party APIs in your own projects okay I've said that, that's all fine you can refer to it later I'm going to wrap up a bit now I think the HTTP it it is what the web is made of it's the wiring that keeps us all keeps it all going together as developers understanding what's happening understanding the requests and responses having some idea of how the content negotiation would work how to do authorization with the HTTP headers how to work with it right down at that level I think is the key skill it certainly stood me in good stead you can go a long way just refreshing the browser and hoping for the best but hopefully here I've shown you both some theory some real examples but also some hands on tools that you can go back and try and that will help you to work with HTTP but also to debug it and potentially to develop some more some more advanced things than what you've already been doing especially as we move to increasingly like headless API backend something completely different on the front end web sockets and Ajax and understanding how to inspect all that transfer I think is absolutely key so the slides are there they're not actually because I haven't created the link yet the slides will be there and I will tweet them very soon the feedback for Drupalcon is done directly through the schedule so if you visit this talk now you can say whether you liked any of it none of it some of it some of it was useful some of it could be better all of your speakers massively appreciate this like leave me some feedback that'll be awesome but all of your speakers have taken a lot of time to prep and they massively massively appreciate your feedback it means a lot to them so if you do have time or could make some time to do that that would be awesome for everybody I do have time for questions so if you want questions start wondering to the mic if you think of a question later or you don't want to stand in the middle of the room and use the mic that's fine you can get in touch with me I am happy to communicate with you um my next point is somewhat undermined by nobody getting up and running for the mic which is also fine I am happy to not take questions um awesome thanks for spending time with me if you want to come in that's fine okay so I have soft question so um how did you learn on this mostly by breaking stuff so my strong points are very much in server-side development as an all-round web developer I am okay right to the minute where it leaves the server so we are working in a team by definition you become expert in the stuff that no one else really does um then I guess I was just really interested in data transfer and APIs it's so frustrating when the data exists on the internet but you can't list it in a way you want people put pictures of their opening hours like a photograph of their opening hours times on their restaurant website and there's no standard way of exchanging it and that's just it's inefficient and it's deeply annoying to me so that's kind of how I started getting involved in APIs the example that you've seen here I built that, that's my open source project I'm just stepping down as a maintainer now after six years that grow and seeing lots of developers get some experience on that API and moving to a website and apps that use it as well as seeing what people do with that data particularly because it's all the PHP conference community data um it's really interesting Larry Garfield did a great one where he there was some debate about how many new speakers there are at conferences like what percentage of conferences are new speakers and what percentage is just the same people giving the same talk year after year after year so he did some analysis pulling the data out of this API saying well when at this event this speaker has no previous talk so we're calling them a new speaker and these speakers all have previous talk so they're old speakers and he did some analysis on that that is not what I designed this data for this data is for giving feedback to speakers so they can be accepted at conferences where we haven't seen them speak but by making it available over an API we were able to reuse the data and he produced this he produced this actually a bunch of different sets of analysis where he had just made loads of requests to the API our rate limiting is a soft limit right now so that was fine my sis admin did ask me what happened to the server and then I saw Larry's bug post and I was like that happened to the server so it's mostly about that it's mostly about wanting to work with it and being a consultant and having to kind of make it up until it worked someone else is at the mic now, hi hi, technical question I've been messing around with error of messages and things recently I've discovered that if you've got a 404 situation and I'm trying not to make this too drupal focus but if your CMS is handling that and is sending back a nice message that says oh what a shame we haven't got your page and so on if you also send a 404 header then the browser may not show any of your nice page it just it shows its own error is that what you expect and is that what should happen? Yeah browsers are trying to help and that's one of the reasons why I use copy as curl because sometimes the browsers will rewrite your headers in attempt to fix something that they don't think should be happening because they don't understand your use case this is a really good point and it's a difficult one the fail whale pages where you do get a genuine page with a picture of a sad panda or something normally come with a 200 ok status and I think there's a difference between presenting a oops sorry message to the user in a web context versus a 404 and potentially a more meaningful message in an API context so yes sending 404s the browser will sometimes make the browsers do stuff in which case send a 200 and present information the user can see but if you're talking to a machine over HTTP so it's an Ajax request or response or you're talking to a mobile consumer the API consumer send the 404 and if you have more information send that to no problem I was just curious couch db how the data is stored because I think you said there weren't any rows or columns right does it just come as a JSON string or kind of it looks like a JSON string on the inside it's actually way more flexible than that you can do lots of searching and optimisations and queries on way nested data if you've worked with one go db it's like that but better inside it so it's stored in a sort of structured JSON representation machine format to us it comes and goes as JSON strings so we can work with it with our JSON tools but the internal storage is actually way more optimised than string so it works also you nest it within yeah you just nest it and I've seen it as a really nice implementation for particularly for content you've all had this experience right you have a page with this a block of this has got and that and then it's got some entity and then you want to add a paragraph and then you want to add a heading and then you want to add an image and then that's not table shaped and you end up with all this like mad joins of different data types that know how to be edited and stuff couch db you just throw in another one and if it's a different shape that's fine so every page would just be like a collection of stuff and then you go and edit the stuff so I think it lends itself really well I think you'll see more in this community of couch db I fully expect to be back at Drupalcon actually talking about couch db next year because I think it's hot and I'm really interested to see what happens with the replication stuff and know people are using it in modules in their own projects so having this is my third Drupalcon I still haven't installed Drupal yet I expect that to have changed by the time I come back because your interests are starting to cross over my tech interests way more so but schema list document database design whole of a talk but really interesting topic thank you my pleasure okay I'm a designer so like I should know about all of this sort of stuff but I haven't a clue about it but I just wanted to say thanks because I'm working on a an IoT project that's using a rubber button to update a Drupal database and this is really helpful this is what you need yes so the internet of things stuff again it's all HTTP calls and as we move to I am going to say this on stage microservices okay done now as we move to more and more kind of componentised things that talk to each other little sensors that send us data there's a project in my home city to make smart gnomes they've taken garden gnomes apart and put sensors inside we've got like a low bandwidth radio network and stuff those things phone home all the time we have to be able to handle that debug it and present it in our web applications so there's lots and that's a wonderful story there's lots and lots of applications for this stuff and I feel like I'm scratching the surface a little bit but hopefully it's giving you some tools to go and ship something amazing and tell me some more interesting stories next time I see you alright I'm going to wrap it up there but I'm here the rest of the day and most of tomorrow I don't know lots of people in this community so feel free to stop me and talk to me that would be marvellous thanks for sharing the time