Your channel is amazing. I hope it grows to the extent that you are aiming for. I am a back-end engineer just at the start of my career, and can't wait to extract all the wonderful content on this channel. Thank you.
This is a great video indeed. Thank you very much for sharing your insights on comparing and relating those systems and concepts. These associations give people a great understanding on what these systems are, and what they are doing. Greetings form Istanbul.
Nice, thanks! I would like to add an opinion to the contraints. You have mentioned the scenario as the third point. I would always have thought that this is by far the most important point to consider for making the decision. And the producers are the ones I would have seen in the end of the chain, because they will have to stick to the decision and solve the problem adequately, I think this is often refered to as "language or technique agnostic". And again many thanks for the overview, this helped a lot!
Hello please a question in the text that says ( APIs using these styles are being implemented and described today. Technologies such as REST, OpenAPI, HTTP, ....), why put http together with the others ? since it is a protocol
@rodrigo, thanks for the feedback. HTTP indeed is a protocol but it is an application protocol. REST is the architectural style underpinning HTTP, and while you can use HTTP for transport purposes only, a well-designed REST API will use HTTP's model (request methods, status codes, media types, hyperlinks, ...) and so forth for the API design itself.
Hi Erik, I would be happy to buy a book or book a course to get end to end. A doubt, I am sure missed, Tunnel API is my good old RPC, Intra and Inter messaging etc But I did not get where is REST API is associated with, Is that Query style?
nope, REST is the resource/hypermedia style. proper rest is hypermedia, but for most cases where people claim to do REST they use resources, but don't have a linking model in place.
Thanks Erik. Great Video, nice qualification and diferenciation.Question: When using messaging, even though it is just a transport but also has the asynchronous component, is there one of the 5 styles which suits better than others, or would you view it on a abstraction layer above the transport.
@@ErikWildeThanks for the swift reply. When using messaging e.g. messag queues over JMS. I usualy propose that the application API (not technical) is "embedded" within the message when using messaging. Thus one will have an attribute for the operatio, possibly for the parameters within or extra to the payload (similar query parameters and content). In your video you mention that REST ist typically with http etc. But how would you design an asynchonous "API". I would consider that with messaging (message queues) one would rather use RPC-, or Query- and for sure the event based style. What would you propose?
@@andreskoch3236 now i see! if you're on top of such a messaging fabric, you're by definition in the "event-based" category. there are nuances to that category which the video didn't mention. for example, some messaging models are mostly point-to-point, whereas others are strongly based on publish-subscribe pattern. but in either case, what you're defining are "events", because this is how these messaging fabrics work. messaging assumes that events are self-contained, i.e. you don't have the typical "conversation patterns" over an existing connection that you'll see in all the other styles.
@@ErikWilde Thanks for your reply. I just tried to place P2P and P/S to your styles and I think that P2P suits the tunnel-style best and I agree that the P/S naturally goes with the event style. And yes depending on the calling style in P2P (send and forget for the request, and listen to the event and correlate with the original request) would also fit in the event-style. To simplify it, one really as you suggest can classify P2P and P/S as event style. On designing the api from a model point of view I don't see many articles around. Is ist no so popular (anymore, yet) or just that hardly anyone cares? In my opinion in messaging ("eventing") it would make sense to model the protocol and messages. What is your experience with it?
If you design it properly and as REST has been defined by its creator, REST always is Hypermedia. But most APIs out there that claim to be REST will be HTTP-based and provide resources, but they will not use Hypermedia. So in practice most APIs that claim to be REST are using the Resource style.
the name is used because you are "tunneling" calls into code that is running somewhere. that "tunnel" is used to call a variety of functions available, meaning that instead of having all capabilities represented "on the web" (for example, as resources in the resource style), you are "tunneling through the web" (often using HTTP) into your implementation.
@@ErikWilde Indeed, I do understand what you mean by "Tunnel Style", the idea that your interface is *just* a tunnel to the code (of the implementation). But, I also do foresee possible confusion as this is a kind of "neo-overloaded term". Should you not just use the term "RPC Style" ? Or do you see a difference between your "Tunnel Style" and the "RPC Style"? I do understand "RPC" as the ability to call remotely a part of the code (the procedure), as if there would be a "tunnel" to reach that code from the network. Anyway, thanks for this video which also shows the evolution over time of the integration technologies and their associated (not always one-to-one) styles. When you described the "tunnel style" as > it immediately triggers back the souvenir of the "virtual function table" (*) used by COM and later DCOM. I do remember those times where DCOM and CORBA were promising you that when you call a function/procedure from your code it does not matter if it runs on the same machine or another machine connected via the network... that was just before the "Eight Fallacies of Distributed Computing" talk became popular ;-) (*) www.ime.usp.br/~reverbel/SOD-97/Textos/dcom_corba/Paper.html | it looks like the original specifications have disappeared from the Microsoft website :'(
@@patricekrakow thanks for your comment! i do agree that the tunnel style also could be called RPC style, and i think i even did this in initial presentations of the five styles. over time i thought avoiding acronyms and "technology terms" (sometimes "RPC" is used to name specific protocols, such as here: tools.ietf.org/html/rfc1057) would help, which is why the style now has a different name.
![Chuckyy - Devil Hours [Official Music Video]](http://i.ytimg.com/vi/f3wZGj0VnZU/mqdefault.jpg)
This is a gold mine channel. I'm very happy to come across your channel today
thanks, mahesh, this is very much appreciated!
Your channel is amazing. I hope it grows to the extent that you are aiming for. I am a back-end engineer just at the start of my career, and can't wait to extract all the wonderful content on this channel. Thank you.
thanks shoumik, that's very kind of you. spread the word! ;-)
Thanks for sharing your knowledge and expertise. Greetings
Thank you so much. These information are very helpful for me as a technical writer.
This is a great video indeed. Thank you very much for sharing your insights on comparing and relating those systems and concepts. These associations give people a great understanding on what these systems are, and what they are doing. Greetings form Istanbul.
thanks, yasam, and greetings from zurich!
Nice, thanks!
I would like to add an opinion to the contraints. You have mentioned the scenario as the third point. I would always have thought that this is by far the most important point to consider for making the decision. And the producers are the ones I would have seen in the end of the chain, because they will have to stick to the decision and solve the problem adequately, I think this is often refered to as "language or technique agnostic".
And again many thanks for the overview, this helped a lot!
Hi Erik, thanks for the video. Nice explanation.
Hello please a question in the text that says ( APIs using these styles are being implemented and described today. Technologies such as REST, OpenAPI, HTTP, ....), why put http together with the others ? since it is a protocol
@rodrigo, thanks for the feedback. HTTP indeed is a protocol but it is an application protocol. REST is the architectural style underpinning HTTP, and while you can use HTTP for transport purposes only, a well-designed REST API will use HTTP's model (request methods, status codes, media types, hyperlinks, ...) and so forth for the API design itself.
Thanks for the video. How is RESTfulAPI related to the five styles?
True REST is defined to be hypermedia, but many who call their API RESTful are not using hypermedia, but instead are using the resource style.
Hi Erik, I would be happy to buy a book or book a course to get end to end.
A doubt, I am sure missed, Tunnel API is my good old RPC, Intra and Inter messaging etc But I did not get where is REST API is associated with, Is that Query style?
nope, REST is the resource/hypermedia style. proper rest is hypermedia, but for most cases where people claim to do REST they use resources, but don't have a linking model in place.
@@ErikWilde Thank you. Honest, I am not sure I understand linking model means. Can I kindly request for ref link please.
@@granand sure, check out this one: ruclips.net/video/zwuoYgLgDUM/видео.html
@@ErikWilde Thanks a ton Erik.
Thanks Erik. Great Video, nice qualification and diferenciation.Question: When using messaging, even though it is just a transport but also has the asynchronous component, is there one of the 5 styles which suits better than others, or would you view it on a abstraction layer above the transport.
hey andres. what exactly do you mean by "when using messaging"? what is the foundation that you want to build your API on?
@@ErikWildeThanks for the swift reply. When using messaging e.g. messag queues over JMS. I usualy propose that the application API (not technical) is "embedded" within the message when using messaging. Thus one will have an attribute for the operatio, possibly for the parameters within or extra to the payload (similar query parameters and content). In your video you mention that REST ist typically with http etc. But how would you design an asynchonous "API". I would consider that with messaging (message queues) one would rather use RPC-, or Query- and for sure the event based style. What would you propose?
@@andreskoch3236 now i see! if you're on top of such a messaging fabric, you're by definition in the "event-based" category. there are nuances to that category which the video didn't mention. for example, some messaging models are mostly point-to-point, whereas others are strongly based on publish-subscribe pattern. but in either case, what you're defining are "events", because this is how these messaging fabrics work. messaging assumes that events are self-contained, i.e. you don't have the typical "conversation patterns" over an existing connection that you'll see in all the other styles.
@@ErikWilde Thanks for your reply. I just tried to place P2P and P/S to your styles and I think that P2P suits the tunnel-style best and I agree that the P/S naturally goes with the event style. And yes depending on the calling style in P2P (send and forget for the request, and listen to the event and correlate with the original request) would also fit in the event-style. To simplify it, one really as you suggest can classify P2P and P/S as event style. On designing the api from a model point of view I don't see many articles around. Is ist no so popular (anymore, yet) or just that hardly anyone cares? In my opinion in messaging ("eventing") it would make sense to model the protocol and messages. What is your experience with it?
So REST comes under which API Style?
If you design it properly and as REST has been defined by its creator, REST always is Hypermedia. But most APIs out there that claim to be REST will be HTTP-based and provide resources, but they will not use Hypermedia. So in practice most APIs that claim to be REST are using the Resource style.
Hi Erik... great video..., But I am having problems with the tunnel analogy for this style of API...can you elaborate?
the name is used because you are "tunneling" calls into code that is running somewhere. that "tunnel" is used to call a variety of functions available, meaning that instead of having all capabilities represented "on the web" (for example, as resources in the resource style), you are "tunneling through the web" (often using HTTP) into your implementation.
@@ErikWilde Indeed, I do understand what you mean by "Tunnel Style", the idea that your interface is *just* a tunnel to the code (of the implementation). But, I also do foresee possible confusion as this is a kind of "neo-overloaded term". Should you not just use the term "RPC Style" ? Or do you see a difference between your "Tunnel Style" and the "RPC Style"? I do understand "RPC" as the ability to call remotely a part of the code (the procedure), as if there would be a "tunnel" to reach that code from the network.
Anyway, thanks for this video which also shows the evolution over time of the integration technologies and their associated (not always one-to-one) styles. When you described the "tunnel style" as > it immediately triggers back the souvenir of the "virtual function table" (*) used by COM and later DCOM. I do remember those times where DCOM and CORBA were promising you that when you call a function/procedure from your code it does not matter if it runs on the same machine or another machine connected via the network... that was just before the "Eight Fallacies of Distributed Computing" talk became popular ;-)
(*) www.ime.usp.br/~reverbel/SOD-97/Textos/dcom_corba/Paper.html | it looks like the original specifications have disappeared from the Microsoft website :'(
@@patricekrakow thanks for your comment! i do agree that the tunnel style also could be called RPC style, and i think i even did this in initial presentations of the five styles. over time i thought avoiding acronyms and "technology terms" (sometimes "RPC" is used to name specific protocols, such as here: tools.ietf.org/html/rfc1057) would help, which is why the style now has a different name.