rest api : good for exposing crud operations rpc : good for exposing several actions Graphql: Good when need data filtering on client side.(Flexibility)
Thank you for creating this video. I was a bit confused about the use case for both RPC and GraphQL but now I understand the tradeoffs well enough to know when it's worth using one over the other. One thing I would've liked though, which maybe useful for future videos, is to have an example use case for each, that goes into detail for a simple application, which would illustrate tradeoffs potentially better.
"with rest and rpc the api often returns fields that the client doesn't use" -- this is true, however, modern rpc frameworks like grpc do have things like FieldMask which solves this problem.
really appreciate this. As others have noted...too many go straight to the bits and bytes and skip the practical considerations. Great video. Two thumbs up.
Thank you for this series. Learnt a lot of important stuff that is not so easily available. Suggestion: please add some examples of each case, maybe you can use a tool like postman
I don't understand, why would anyone model Search using REST model, using a PUT, as shown in your video (6:31). Search is more alligned to a GET with query params.
Important aspect of RPC that was not mentioned: in general RPC leads to coupling of client and server, that is, implementation of server actions is reflection of what client (or particular implementation of client) needs. This limits flexibility and reusability. It is great for creating APIs that are going to be used closely with a particular product, but that limits potential future exposition of the API to other usages, like launching a public API for the product. Since the server API was designed around product needs (usually more high level actions and lacking granularity), moving to a different use case or opening up the API might be difficult to untangle.
Nice session that provides overview of the various types of API. Separate videos detailing each of the types along with examples would be really helpful!
There's nothing stopping you from customizing the REST Api to get smaller payloads by using query params to tell the server what fields you want. /api/user/1?q=name,age for example would return name and age only.
Hmm, true, now imagine a client dealing with all these proprietary conventions. Add filtering and sorting to the mix. Also, how would one discover all these conventions? Documentation you say? And then deal with the results which will be expressed how the developer of a particular API method felt the day he implemented it. There is no consistency, no generic way to discover capabilities, hence no tools to help out. Some APIs went the way of OpenAPI specification to bring some sanity into the process. GraphQL is that plus more because it brings to the fore the familiar concept of a schema composed of types.
Hi Amey, usually the best way to identify if an API is REST or RPC is by reading the API docs. You can also rely on the API URLs to give you hints. REST follows a very structure resource naming pattern whereas RPC will include action oriented naming in the URLs. To be absolutely sure, looking up the docs is the best way.
Not enough info on RPC. The pros/cons of rest api and rpc depends on how you implement the apis in the backend. You could have a rest api that does more actions too (search, retrieve, update and return updated resource for example)
It depends. Some API providers do provide a combination of API paradigms, but only when there is a clear separation of domain contexts. For example, if you provide a users endpoint using REST, it's probably best not to provide an RPC API for the same users data either. But if it's for a completely different context, then it might be acceptable.
With regards to this it depends on the layout of your data. But as an example you might keep your user data and order data separate and to keep track of who has ordered what you use the user id. This presents a problem where you have to GET the User data for their id first and then pass that user id to a second GET method for all the orders a User has made. It doesn't necessarily have to be this way but these sorts of things can generally happen with REST APIs. In other APIs like GraphQL you don't have to worry about this sort of thing because relationships between data are generally more expressive. And allows stitching together of different schemas to get the desired result. As with the example above you can get around it with a REST API but only if the data shares some commonality. For situations where the data doesn't share common information you are kind of stuck. Such as grabbing events in your area as well as the predicted weather for those events. Especially if you are using the API of another service such as openweathermap's API.
rest api : good for exposing crud operations
rpc : good for exposing several actions
Graphql: Good when need data filtering on client side.(Flexibility)
Thank you for creating this video. I was a bit confused about the use case for both RPC and GraphQL but now I understand the tradeoffs well enough to know when it's worth using one over the other. One thing I would've liked though, which maybe useful for future videos, is to have an example use case for each, that goes into detail for a simple application, which would illustrate tradeoffs potentially better.
That's some really useful feedback, I will keep that in mind for future videos! Thanks for the support!
Best IT explanation video watched ever! Clear and Precise! Love it!
Wow, thanks for the kind words!
"with rest and rpc the api often returns fields that the client doesn't use" -- this is true, however, modern rpc frameworks like grpc do have things like FieldMask which solves this problem.
really appreciate this. As others have noted...too many go straight to the bits and bytes and skip the practical considerations. Great video. Two thumbs up.
Thanks for such a good series. Its quite hard to find such series. Mostly are based on coding only and dont cover the theoretical part.
Glad you like them and thanks for the positive feedback!
Thank you for this series. Learnt a lot of important stuff that is not so easily available.
Suggestion: please add some examples of each case, maybe you can use a tool like postman
I’m glad you found the series useful! Thanks for the suggestion, I’ll keep that in mind for future videos 👌
Great explanation Thanks! And thanks for mentioning RPC APIs. They are the right solution 99% of the time in my experience.
Thanks for your support!
And yes you’re absolutely right - RPC is a good fit in most cases.
But why the majority of companies are still using REST?
@@r0ck566 I think it is 'cause rpc is built using http2 and many client+server architecture is on http/1.1
Thanks for explaining in simple and easy way.
Happy to help 🙂
Best explanation I've seen so far.
Thanks for your kind words 🙂
I don't understand, why would anyone model Search using REST model, using a PUT, as shown in your video (6:31). Search is more alligned to a GET with query params.
The way you explain is just simply golden. Subscribed and Liked.
Thanks for the kind words 🙂
Why is for search in your REST example the PUT method being used and not the GET method?
Important aspect of RPC that was not mentioned: in general RPC leads to coupling of client and server, that is, implementation of server actions is reflection of what client (or particular implementation of client) needs. This limits flexibility and reusability. It is great for creating APIs that are going to be used closely with a particular product, but that limits potential future exposition of the API to other usages, like launching a public API for the product. Since the server API was designed around product needs (usually more high level actions and lacking granularity), moving to a different use case or opening up the API might be difficult to untangle.
Thank you very much. Saved me a lot of hassle.
really appreciate this. this fit what i am searching for
Great video, easy to understand and with a lot of useful information.
Clear and useful comparison.
Thanks Shawn 🙂
Nice session that provides overview of the various types of API. Separate videos detailing each of the types along with examples would be really helpful!
Great video, thanks!
That was a neat video about them . I really enjoyed you explanation . Thanks
Nice Presentation with well explanation.
Thank you, I’m glad you enjoyed it :)
@@ambientcoder5462 You can also create a video on FAST api
Amazing overview
This is great!
Glad you liked it :)
Great information & explanation. Thank you .
Glad it was helpful!
Great explanation. Thank you so much.
Glad you liked it!
Just what I was looking for!
Brooo you are awesome 🤘🤘🤘, I am grateful to discover this channel
Thanks bro! 🤘🤘 Hope you enjoy the content 🙂
Amazing series!
Excellent, Thank you!
Very helpfull Thanks.
6:05 I think mean, "You don't want to use _verbs_ ..." not "nouns"
Thank you for the great content. Please keep posting more videos.
Thank you for the kind words :)
There's nothing stopping you from customizing the REST Api to get smaller payloads by using query params to tell the server what fields you want.
/api/user/1?q=name,age for example would return name and age only.
Yahoo's Elide implements this very well
Hmm, true, now imagine a client dealing with all these proprietary conventions. Add filtering and sorting to the mix. Also, how would one discover all these conventions? Documentation you say? And then deal with the results which will be expressed how the developer of a particular API method felt the day he implemented it. There is no consistency, no generic way to discover capabilities, hence no tools to help out. Some APIs went the way of OpenAPI specification to bring some sanity into the process. GraphQL is that plus more because it brings to the fore the familiar concept of a schema composed of types.
excellent
Very helpfull video, thank you!
I’m glad to hear that, thanks 🙂
Thanks very much, that's really helpful.
Thank you for the excellent video. But why use PUT for a search instead of using GET?
nice and clean
what are AWS APIs. Just by looking at the API its hard to tell whether they are RPS or REST? Or I am missing some pointer to identify?
Hi Amey, usually the best way to identify if an API is REST or RPC is by reading the API docs. You can also rely on the API URLs to give you hints. REST follows a very structure resource naming pattern whereas RPC will include action oriented naming in the URLs. To be absolutely sure, looking up the docs is the best way.
in order to use RPC such as gRPC you must use its proto file and generate a stub file in any language of your choice.
thanks!
Not enough info on RPC. The pros/cons of rest api and rpc depends on how you implement the apis in the backend. You could have a rest api that does more actions too (search, retrieve, update and return updated resource for example)
Thanks!
What happens to SOAP web services? Many enterprises use it a lot.
Can two of these be combined in a single application?
It depends. Some API providers do provide a combination of API paradigms, but only when there is a clear separation of domain contexts. For example, if you provide a users endpoint using REST, it's probably best not to provide an RPC API for the same users data either. But if it's for a completely different context, then it might be acceptable.
Great video
I guess you meant "you don't want to use verbs" at 6:05
You’re right I got that wrong! Thanks for pointing this out.
Love you.
where is soap?
7:55 excuse me, could someone explain why we cannot reach a subresource just by going to PUT /users/user-1/deactivate ?
With regards to this it depends on the layout of your data. But as an example you might keep your user data and order data separate and to keep track of who has ordered what you use the user id.
This presents a problem where you have to GET the User data for their id first and then pass that user id to a second GET method for all the orders a User has made. It doesn't necessarily have to be this way but these sorts of things can generally happen with REST APIs.
In other APIs like GraphQL you don't have to worry about this sort of thing because relationships between data are generally more expressive. And allows stitching together of different schemas to get the desired result.
As with the example above you can get around it with a REST API but only if the data shares some commonality. For situations where the data doesn't share common information you are kind of stuck. Such as grabbing events in your area as well as the predicted weather for those events. Especially if you are using the API of another service such as openweathermap's API.
From 7:13 Is not true. You can select particular field from entity not downloading whole entity.
yo sir, why aren't you posting now a days. please post series like this. thankyou
I apologize for the lack of videos. I hope to find time to make videos in the near future. Thanks for your support, really appreciate it!
cool!
great
Thanks 🙂
nice
Thanks 🙂
deactivate, rest, PATCH /users/user-1 , status: 'deactivated'
there's no need for actions
Try to reduce noise of background music, when it's on high nodes you are barely audible, TBH it's not adding any value.
bas na bhau
kiti ata .rest paryant mahit hot ata jara jast hotay
There are no such a “problems” in Rest CRUDs. It is not a protocol, but an agreement, a pattern
7:45 is not true
He adds "not in a RESTful manner, anyway" so that should make his statement true.
GRAPHql is always POST.
the high hats of the rap music in the background are very distracting