Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
okay right welcome everyone to the what's known as the graveyard slot yeah the final day of the conference after lunch you're all probably feeling a bit sleepy and you know don't worry if you sort of feel the urge to nod off during this presentation
I won't be offended please try not to snore though it does it doesn't bother me but it might bother the bizzle next to you if I start to snore though some please kick I want to talk today about hypermedia hypermedia api's or Happy's and i'm
also going to talk about rest but i'm going to start by really saying a few words about the architecture of the of the world wide web itself and roy failed him roy failing who was one of the principal architects of the web had this to say about the architectural
style he said the world wide web has succeeded in large part because it's software architecture has been designed to meet the needs of an Internet scale distributed hypermedia system an Internet scale distributed hypermedia system I'm going to come
back to those words later now if you cast your minds back to the early days of the of the web if you're as old as me it's like seems like to come yesterday really but I'm talking about the early 1990s so 20 years ago maybe the web was going through
a period was actually experiencing some issues it was it was finding it difficult to scale you know talking millions of websites at this time rather than sort of hundreds of millions like we have now but it was going through a period when it had had these
growing pains and fielding and others looked at what the problem was and they did some theoretical work on how you build network network systems and fielding came up with a number of key constraints that taken together gave rise or would give rise to an Internet
scale distributed hypermedia system that had the desired properties of such a thing the desired properties that you wanted in the world wide web and he compared that theoretical model against what they were actually doing at the time with the web and that
resulted in a number of adjustments being made to some of the core protocols in particular HTTP 1.1 came out as a result of that work and also there was a standard new standard for you our eyes when they're probably other things as well and as a result
of those corrections yippee the Internet's scaled a lot more a lot better than it had in the past an evidence of that is Google who very rarely give out any kind of data on these things announced in 2008 that they were aware of in excess of one trillion
unique URLs and that's scalability for you obviously the numbers probably much bigger since then but nobody nobody knows what it is these days so fielding went on to publish this theoretical work in his dissertation PhD dissertation and the section of
that dissertation is actually chapter 5 referred where it talked where he talks about these internet scale distributed hypermedia systems became known as as rest that's what he calls it that's where the word comes from or the acronym so rest fundamentally
is is the architectural style that has been used to guide the design and development of the web itself so in a sense jim was already restful it's an app it's a web application so it runs on the web it's restful I come back to the enemy so fielding
actually grouped these constraints into these six categories I'm not going to go into detail on these as this massive amounts of resources on the on the internet which go into these things in extreme detail the important point that I want to make is that
when we're designing applications were building things like joomla we shouldn't in unintentionally violate these constraints because if we do so then it hampers the our objective of building internet scale distributed hypermedia systems I do have I
want to say want to pick out one or two other constraints because I think that particularly relevant to what we're doing right now we work with web services the first is actually pretty obvious it's it's a client-server system so typically you
the web browser is a client and Jim was running on a server that's your client server but the it's important to realize that it's a loosely coupled system clients and servers actually actually need to be able to not depend too tightly on each other
they need to be able to you need to be able to develop them at different times with different groups of people they need to be able to evolve at different rates so it would know but it would be no good at all if you know somebody at IBM or something upgraded
their web servers one night and everybody else in the internet suddenly came in next morning and their browsers didn't work anymore and the way to do that is that the clients and servers have to be able to share an understanding of what they're doing
of the particularly of the messages that are going back and forth between them they need to develop this shared understanding that's why I put it in big letters there that's really important the important point then another one of the key constraints
is that the system is basically is based on resources with the standards all talk about resources so an article on a joomla site for example is a resource and for those of you are into domain driven development that's basically your your domain objects
that you're talking about there and those resources are identified by you our eyes that's part of you I you are I stands for Uniform Resource identifier use when you're talking about identifying resources and the it's important to realize that
a resource can actually have multiple URIs that's perfectly acceptable and in fact the you our eyes may depend on time as well as that one as that example illustrates and you manipulate resources via representations so this is not a pipe it's a representation
of a pipe is an image of a pipe we manipulate articles on a joomla site not directly but we manipulate them through representations so you do a get request on a joomla article it sends you a representation of that article you change it you post it back again
that updates that article but you're always working through these representations the messages that flow between clients and servers need to be self-descriptive there needs to be enough information in a message so that the recipient can understand what
it means and this is encapsulated actually in the media type so if if I were to send a server adjacent message I would say this is application Jason and I could then assume that the server understands application Jason I don't need to send the Jason spec
along with the message in order to describe it because the media type says yeah this is adjacent message if you don't know son Jason tell me you don't understand Jason else and something else but anything beyond that anything outside of the media type
needs to be within the message so the message so your media type is like the basic level of understanding of that message and I think beyond that needs to actually be in the message in some way or another it's not always easy and then the final constraint
I want to look at is the hypermedia constraint sometimes known as hate OS this is a horrible acronym for it it actually stands for Hyper media is the engine of application state and what this means is that clients drive application state by following links
which really is exactly what everybody does every day on the internet with a web browser you've got a web page you click on links what you're doing there is you're changing the application state by following a link and when we start talking about
things that aren't web browsers that are sort of machine to machine type communications links which was what we're talking about with web services then that's what fundamentally you're doing the following these type of media links in fact it's
those links that make it hypermedia in the first place you know what is hypermedia it's media with hyperlinks that's what hypermedia is awesome ending form should pretty much the same sort of thing it's important to realize that that clients should
not try to read any meaning into the structure of a URL you should never get into a situation where a client passes a URL and said oh that means that that means that they should just treat them as opaque strings there's one sort of tight it's not really
an exception but you are I templates where the server gives you a template which has like substitution tags in it and you can put the variables into it in order to generate URI that's fine but the client should never be in a position where it tries to
[ ... ]
Nota: se han omitido las otras 4.313 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.