Creando APIs Hypermedia

Extracto de la transcripción automática del vídeo realizada por YouTube.

thanks everyone can everyone hear me okay because I can't tell if my voice is travelling so so yeah cool everyone's thumbs up at the back that's good okay my motivation for bringing this talks to this conference was to try to get across the idea

that if everybody you can start building their I either ap is using a kind of a standard way a standard format of using hypermedia we can make the web a lot more of a useable place for developers this talk is very much geared towards people in this room who

are creating this stuff every day if we can all decide and agree that create that using hypermedia is a good idea we will automatically be able to kind of use the web as a way of being able to scale our API is to high volume of traffic to be able to use the

facilities that the web provides to to cache everything and just to be able to make things better and that's what I hope that everyone can take away from this talk that using hypermedia correctly and appropriately will help achieve that goal so first of

all who am I and why am i standing here talking to you about hyper media I blog a little bit on my personal blog no Cariad occurred at UK I talk at conferences this is the this is my second talk that I've done on the the field of rest in general I also

talk about a micro framework called Silex I've been involved with the community for the PC community for probably about five years or so now maybe longer I lose track of time but I'm a software engineer and manager and I work for the in Vica group

and my t-shirt the likud group consists of indie carousel session digital and sends to your labs UK we are hiring so I'm sure everybody's pretty much aware of that by now but we always are I'm from Scotland I love putting this slide up because

I can put a massive flag of Scotland up on a big screen so everyone can see um okay so let's get into the little bit about why I'm here to talk about I know Oh actually before I do move on to that that's just some of my contact details there so

the first thing I want to talk about a little bit is the architectural styles of creating api's on the web there are many some of them are more successful than others and we're going to run through a couple of they're kind of the ones that we shouldn't

really be following some of the styles that are they can work for some certain for certain situations and sometimes it's okay but there are some issues with those things with those ways of working we have lots of lots of api's use the web simply to

tunnel data through they don't use the protocol they just use it as an it as a way of being able to get a message from one place to another place and a lot of those API is look a little bit like this RPC style api's you issue a get requests include

all of the information in the URL and have things that change state on the behavior from just following a link there are some reasonably obvious pitfalls of doing this things this way if that for example was a link that a web spider could follow every 12 hours

or so and Google comes along and indexes your of site it ends up creating a new user account and that's because we're not using get in the way that it was designed get is supposed to be a safe method you're supposed to be able to issue a get request

against anything on the web and it will return the resource it doesn't change anything to do with that resource yes it can do some other things it it can increment counters it can you can be tracking statistics you can do or some other bits and pieces

off of the back of having a get request but it shouldn't change the state of a resource I just kicked that light this works against the web you can't cache that resource it's not this isn't a read-only resource this is modifying the behavior

of a server is modifying State on the server side this these webs these these api's sit on a scale and I'm gonna go through each of the levels there's three levels in this scale called richerson maturity level and they describe how advanced an

API is in terms of getting to level three which is titled the glory of REST API is at level zero are said to be sitting down at the bottom in the swamp of pox which is a great term pork standing for plain old XML this is where api's have no semantic meaning

they're just blobs of data they could be in any format and you can consume them you have very you have clients are very hardwired to understand the exact specifics of your API then nothing can be implied or derived from those api's they have no semantic

meaning or Jason I will talk a little bit more about Jason later on and I'll leave that for later he isn't it a quick example of some just a plain old XML file everyone's probably familiar with these with this sort of thing it's just some it's

just an XML blob none of these things really mean anything there are written in English of course but you can understand them but for a computer or our client is trying to understand these this API it has to know exactly what each of those little bits mean

and is very specific to your implementation it's very domaine specific we can't represent something else using a similar format we have to design another one other another architectural style which lives in this register maturity level zero is the

ws star standards and these are the this is soap all request server soap are done using post an HTTP POST request they don't use anything else they're just tunneling data using post and it re-implementing a whole bunch of features like caching like

any kind of metadata everything else has to be implemented in soap we can't leverage anything it's out there using soap because it just uses it as a tunnel soap clients are built off of using these whistle files they are the clients are very very intrinsically

tied to how you do how you how you use that API this is okay if you're using a language of supports this really well like Java you can point the Java after utter whistle API after whistle it pulls it down and generates a client on your client side and

you can just start using it it doesn't work quite so well if you're in another environment like in PHP or using something else it's very complex the the soap envelope if you ever actually have had the misfortune of having to dive into it so painful

about it looks like and what things are how things are represented it's really difficult to read this is very much a machine that something is targeted for a machine so how do we get up to Richerson maturity level one from from sitting at the levels of

RPC XML RPC and soap that kind of thing we hit level one by identifying resources this is the pretty URLs part there are lots of people think of when you say I have a REST API the thing immediately they jump in saying or like you so you have nice little URLs

which address things yes yes you do because the reason why we have those is because you're identifying resources using a name and that name is the URL so this is quite often what people think of when you say that you've got a REST API what you don't

have in a in a restful api usually is verbs inside the URL this is quite a bit of a clue about whether or not your service you're thinking is heading in the right direction for for creating something it will exist on the web in a kind of web friendly way

[ ... ]

Nota: se han omitido las otras 3.676 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.