Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
good afternoon how nice to see you all I am very excited about giving this talk but it wasn't quite expecting so many people so i can only say thank you very much for coming along this afternoon i'm going to be talking about rest and this session is
aimed very generally at web developers i may as well say now before it becomes any more obvious that i'm not a drupal expert i'm a rest expert that's what i do i love api's I care about api's and I spend most of my time in either straight
PHP or any one of the other PHP frameworks so um in a great many things none of them involve Drupal basically the only thing I knew about Drupal before i came to drupalcon is that I like to drink with Drupal people so is very pleased when they accepted my
talk awesome so um I have some giveaways for you and I will do that right at the end of the session when I take questions have you asked me a question and you're in the first two people to ask me a question I will give you a copy of my book if you have
questions at any other point during the session I am totally happy to take interruptions but to get my attention you should go to the microphone because you can't ask me a question until you get there so don't raise your hand go to the mic and that
way the people listening to the recording will hear it as well as everybody behind you in the room so here we go rest rest is all about data the acronym stands for representational state transfer and it's pretty much what it says on the tin right so we
deal in transferring representations of data everything is a representation of a resource or of a collection and we probably represent it in JSON in XML maybe you serialize your PHP or you like yeah Mille or Klingon or I don't really care but you represent
your data any way that you want to everything in your system is a resource so a user is a resource an article is a resource a comment is a resource would consider everything as a resource and we transfer representations of it when you're getting lists
of resources we call those collections like most very hyped technologies it's mostly about the words so a thing you should say the word resource and for any kind of the list you should say the word collection now your arrest expert rest is not just about
pretty urls you do need to have really good routing to do rest well but the urls are very important they tell a story I have some example urls on this slide so you can guess that the top example / articles is a collection of articles you might guess at articles
/ 2756 is an individual article resource you're all with me so far this is excellent also you will see these sub resources so I have a specific article resource which has a comments collection associated with it so rather than getting all the comments
in the world ever and filtering for this article we can make them available as a sub resource of our article and then as an example I've got a finally an independent and individual comment resource so those URLs create too much describe the data that exists
at those URLs and thinking of data being at the URL is a really good way to think about how this works typically when we talk about the web we are talking about using rest with HTTP that means that this talk is about rest and it's going to involve quite
a lot of HTTP because that's the example that I'm using HTTP is an awesome format it has lots and lots of features that make implementing elegant data transfer very very easy so I am going to talk to you about verbs and how we use those in a restful
api i'm going to talk about status codes why they are so important and under what conditions i will hunt you down and kill you and i'm going to talk about headers and i want to talk about how those fit in also in the context of a browser and also of
a mobile device so I've got some examples for all of those things will start with verbs verbs define the operations that we perform on our resource so we use the same URL regardless of whether we are reading a resource creating one changing one deleting
one and the verb tells us which of those things we're doing as web developers you already know about get and post I'm going to add two more into that list for you and that's the put and delete verbs when we use the get verb on a connection that
will fetch all the resources in the collections so we'll get representation representations of each resource in a collection if you do a get request to a single resource you'll just get the representation of that resource and the representations are
the same regardless of whether it appears in a collection or as an individual resource we use the post verb to create a new resource so you make a representation of the resource you craft together whatever representation language you're going to use and
you post it to the collection that the new resource will live inside so it's a bit like doing an insert on a mysql table you just send the data without the primary key and the database comes back and gives you the last insert ID and in this case the date
the breast server will come i can give you the URL where that resource will exist we use put to change a record so you would get a resource change it as you need to and then use the put verb to put it back where it belongs I have create in brackets because
you can put a new record to a known you are i if the client gets to make the decision about what the uri will be that's not often the case hence the brackets guess what the delete verb does right so you have a resource at a particular URI you want to delete
it make a request with the delete verb good you're keeping up let's talk about status codes status codes are the headline news they come back with the response from a server and they tell you what happened typically these are the most common ones 200
means everything is okay most frameworks CMS's and other tools will emit a 200 by default if I make a request to your API and there's something wrong and you send me an HTML error message and a 200 status code that is the moment I will hunt you down
and kill you I integrate with a lot of other people's api's i'm just getting less and less tolerant as i get older the 201 status is something that you will see in restful services because we are posting a new resource representation to a collection
and creating a record you are going to see full on examples of this soon but it was quite cody so I thought we could do the story first and then I would drown you with code so the created tells you that something was created right the 204 response is one that
you do sometimes see and it's literally 200 everything's cool and I have intentionally sent you empty body content this is used for example when you delete something right if you request the server deletes something I did delete it I have nothing to
tell you quick it's gone so it's not really a 200 because if you saw 200 with a blank body you might be confused and we us use 204 for that specific case anything beginning with a 2 is good news anything beginning with a 3 is yes but there's something
we need to talk about so the example here that I've given is 3044 not modified you would use this with something like a last modified or an e-tag header where you've requested the resource you've received the resource it had some information about
its version in it next time you request the resource you send information about which version you have if you have the current version the server says 304 and it doesn't lead to send you anything else you just use the version that you have so that saves
repeat transmission of data that does not change often very very useful for sites which need to scale anything beginning with a 4 means you did something wrong the 400 bad request is kind of lean on specific I really know what's going on here so you probably
sent our data or the server was stupid and didn't understand some combination of that the 404 is specifically you asked me for a record that wasn't found so literally did to get requests on something and it doesn't exist it is not there so those
are the common status codes and there are many many more there's a fabulous Wikipedia page if you want to lose the rest of the session reading that status codes you should look it up right now and it has a very improbably large list of Slater's codes
the things that you need to know are you should go there and you should use the right status code even if it's as simple as 400 something went wrong 200 everything's cool that's a good start there are status codes covering all kinds of things from
redirects to problems with you must authenticate your authentication is invalid this record doesn't exist anymore this record was updated since you last used it and so on so there's lots that you can do there to make your api's more informative
to the user the more information that you can give to whoever or whatever is consuming your API the less likely they are to open support tickets and the more likely you will make it to the pub that's the aim of the game let's talk about HTTP headers
[ ... ]
Nota: se han omitido las otras 4.676 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.