Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
I'm Dave and go I'm a Senior Operations guy at data safe now quick plug we're hiring we're an awesome company come talk to it myself or so my colleagues are also around at the conference before that I worked for company called group spaces
for a good few years I have way too many projects I've got so many things on the go at once it's difficult to balance but I'm involved in open source I've got involved with joined in among other projects and if you want to to talk to me or
to heckle me or ask questions then hit DMI on twitter nice short and easy to remember so why am i giving this talk I've built quite a few api's unfortunately most of them are not public so I can't brag about them but I've consumed with a lot
of api's and I've seen what happens when people try to build them without really thinking it through to begin with also I'm very opinionated as I'm sure you'll find out so if you as I said if you want to give me any feedback afterwards
that's fantastic I will be responding to each and every tweet and also if you could leave some feedback on joined in that will also be wonderful and just help me make sure that that this can all improve if it needs to so what this talk isn't about
is rest a lot of people talk about it and that's that's not what I'm going to do I mean it's great and all but there's so much more to building an API than just having you know like you good URL design using the right verbs you've also
got to care about things like the headers that you accept some that you that you give back the authentication the data formats data integrity and documentation yes I didn't say documentation but we'll come back to that later so very very quickly I'm
going to rush through what most rest talks tend cover which is good URL design my advice on this is to make them versioned to make them mean hackable and meaningful so that there's a sense of structure and those are a natural feel to them so something
really simple just you know v1 for the very first version a collection of users a particular user and then attributes relating to them and building up in a structure that makes sense but from a consumer perspective they don't care how we've built things
they don't care if it's really difficult to really complex or really expensive for you to calculate stuff they just want to use it in a way that makes sense to them from what they can see on the outside so use your common sense it's and you've
got to try and take step back and consider how it's going to see him with if you don't have all this deep knowledge about the system one of the things that I see said about api's from time to time less so now fortunately is people throwing everything
in the URL that's not quite what it's for so you don't have for example my API slash search slash term 1 slash term 2 that's what the query string is for that's what it's designed to be used for it so it's for filtering and maybe
some alternate representation and flags the use of things like that so you use it for for example for controlling for paucity you don't use it for saying oh I won XML or all I want Jason there are more semantic ways of doing that you can use it with fire
extensions or headers but they'll come back to that later so just for example the search I mentioned earlier you want to make sure you're using the right tools for the job and again with Jason so with formats you can use file extensions or an accept
header but there there are pros and cons verbs again HTTP has quite a few only two of them you use a lot which get input getting post heads often also comes up occasionally and as I'm sure you all know poets and elites are also useful options kind of comes
into it a bit and that's going to become more more popular in the near future but I find helpful to think things in terms of operating on on a data model as you can see there I'm not going to go through it all but you unless you're building a read-only
API like say Google+ because you know they want to post you must handle getting posts and they're the two basic operations and all clients can handle those no matter how limited they are with the other methods you can emulate those if necessary so these
silky the semantics but still support clients that are really limited so one example I've seen that I quite like for doing this is to have an exclamation mark and then the desired method name at the end and whose posts for forcing that through and that's
from a semantic point of view because post requests are defined to have side effects and so they don't get cached and they last user if you want to if you're doing in a browser if you want to retry the requests and so on but one thing to remember is
that put and delete should have the same effect no matter how many times they repeated so if you if somebody sends a delete message to have to take your endpoint then that should delete the required object obviously but returns success even if they do it multiple
times in a row because it's not going to be anymore deleted it's already gotten and a similar thing with put you're just updating a resource you're over writing it heads is fairly rev and PHP will generally deal with that for you you can detect
it to decide to do less work and less processing but depending on what you're doing that might not be be feasible or useful and options is very rare until fairly recently with the advent of cause so this is something called cross-origin resource sharing
and that's of kind of grand term for getting around the same origin restriction in browsers so with browser you can only send a request to the same domain that you've got the original page from if you want to go outside of that then usually you're
stuffed but with this standards which works in all major browsers of recent version is works properly in IE 10 plus it doesn't it's not quite the same in lower versions of ie it's a different and different objects but normally you won't have
[ ... ]
Nota: se han omitido las otras 3.005 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.