@Gaurav, we should not return list as a response to an API, and should return an object instead. that helps when we need to add a new variable in the response. In that case clients won't break. Say in your example, in the future, if I wanted to add a new variable like "String resonseStatus" along with List, I can't really do that without making change in clients. But if I already returned an object, I could add any number of new variables to accommodate in the future.
I don't totally agree with this approach. Yes, as an API definer, things will get easy for you. However, your consumer should still migrate to the new API version. By returning object as a response, you are saving yourself from changing the contract every time, however you are reducing the clarity of your contract and need to tell a lot in the documentation. I would prefer changing the API contract every time I make a backward incompatible change.
There are only 2 types of explanation for complex Computer Science concepts in this world: - The one you had in universities which you don't understand sh*t. - The one provided by an Indian engineer on TH-cam that would enlighten you in 15 min. Thanks a lot man !
Hi Gaurav - just to clarify the following 1. APIs can expose only "public" methods ( not protected or private methods ) 2. it is a good idea to minimize payloads sent in request objects via POST ( use GET instead ), and sending the routing information or action information in the JSON request payloads makes for dirty APIs.
The best way to design an API for designers is to start with the foundation. The foundation is where most developers get it wrong, from my experience. Everything starts with the why. A simple yet crucial question that one should ask. The why for doing something, triggers multiple conversations that span the user journey, business objective, data contract, data governance, compatibilities, and lastly the use case. Another really good thing I have noticed with a well-defined API is that it also makes you understand if the procurement of data is truly vital or not, thus, helping in prioritizing API A over B. If this API is only relevant to a very low amount of stakeholders, do I really want to design it? The rest are just bells and whistles.
So happy I found this channel!!!!! This is the next level interview prep material. I was focusing on the main, most important topics to study, more language based questions then I started getting System Level questions and didn't have a good explanation until I started watching these videos. The funny part is that I knew most this stuff, but I just drew a blank when asked. I hope to get through the playlist before my next interview!
I think RESTful APIs should work on Resource (in this case Group). We use certain HTTP verbs (e.g. GET, POST, PUT) to manipulate that resource. So the URL of API should be like this: GET /api/v1/groups//admins Notice the resources are in pluralize form (groups, admins, employees). So if we want to get a details for specific admin, we can just append the adminId as well. (GET /api/v1/groups//admins/) Optionally API could expect pagination, limit from URL GET parameters as well... like (?page_no=2&limit=20) PS: Also most people use version in the beginning of URL. e.g. /api/v1/.
Just a small technical clarification.. the whole URL has components called URI - first part is the server address (mapped to a server somewhere using the IP address and port number), after that comes the individual context resources. Instead of model (the URI that comes after server address), let's say context for the actual resource. The next part(s) are the actual requested resources, which consist the name of the api method, and any parameters if present.
Thanks for explaining the application programmable interface. This content is helpful for understanding the structure of an API. Insightful and thought provoking😊
As a Database Developer, I see similar principles and terminology applies to API design as well. As they say, the more you know, the more things seem the same. Cool video bro.
Great video again. Good to see discussion on consistency here. Couple of comments. If the data is huge and if we are going to use IP fragmentation, then typically it is transparent to the application developer. Also it might have been interesting to get your perspective on handling partial success in the API, say for setAdmins, it set admins for the first 3, the 4 user id does not exist/not member of the group, how does it signal error. Thanks
Hi Hemanth, the response can be a complex object, in which there is a list of objects. Each object carrying information about each user. Using this way, we can give information on processing status of d admin. { AdminsProcessingStatus: [ { ISetASAdmin : true, ActionTaken : ExistingGroupMemberSetAsAdmin/AddedToGroupSndSetAsAdmin } ] }
Thank you for this video, Guarav. Extremely helpful and I love your explanations. This has been a great resource as I prepare for an upcoming systems design interview.
As per my understanding about API is: API is something which simply pulls out the data from the data source so that various applications can consume those APIs. Since our data source may or may not interact with other applications that's why we need to create an API. Here data source can be any databases or legacy systems like SAP.
Hey gaurav, great seeing your videos, Wish someone taught me during my interview days, I remember some design questions I was asked - URL shortener, Web crawler and proximity servers(Yelp). You should definitely do these, I personally ask a few when I interview :P
Regarding how to solve the 'number of admins' changed, you can subscribe to group chat changes. You can subscribe to 'participants changed' event same as 'new message' event and etc. You must not query admins if you have them up-to date all the time.
If only there was a button for 100 likes!! I could relate to so many bad APIs written in the past. Now I know. I have been enlightened master! Thank You.
🎯 Key Takeaways for quick navigation: 00:28 📝 An API is a documented way for external consumers to interact with your code, specifying parameters, return types, and possible errors. 01:26 🚫 Misnaming APIs or adding unnecessary parameters can lead to confusion and poor API design. 03:26 ⚡ Additional parameters in API calls can be acceptable for optimization purposes, especially when performance is a critical concern. 05:31 🛡️ Design API errors based on common expectations and the responsibilities of your service. Avoid returning generic errors for all cases. 07:01 🌐 Plan the routing and actions of your API carefully to ensure clarity and prevent ambiguity in the API calls. 08:30 🔄 Avoid side effects in API calls; keep the actions focused on a single responsibility and ensure atomicity when necessary. 09:57 📦 Break down large responses using pagination or fragmentation to maintain efficiency and prevent overwhelming the network. 13:58 ⚙️ Consider data consistency needs; decide if perfect consistency is crucial or if slight delays or cached responses are acceptable for certain use cases.
Hi Gaurav, First of all a big thanks to you sharing these neat and clean, content rich videos. It helped me a lot to clear some of the key concepts which I use on day to day basis. Finally I wish you all the best and I would say "YOU GOT A NEW SUBSCRIBER"!!!😊👍
an API is just a function...wow such a beautiful straightforward definition. I was confused since a week and everywhere they were just saying the things like "it is an interface to connect two software systems", "it is a set of rules and protocols" etc. but no was saying actually explaining it in terms of programming. But Gaurav sir, you just helped me to get through its heart as what it actually is at its core. Thank you so much for relieving my week's pain and confusion. Since it is a function that only care about "what" that is, it hides the abstractions so I'm assuming that it is an higher level function which calls the specific part/module of the system to get the work done and once the tasks is done, it compose the response (generally as an object) and return it.
api isn't a function but an interface (at least not in java). They're like contracts written for achieving abstraction similar to abstract classes but their purpose is generally for abstracting functions. Read about interfaces to understand.
Hi Gaurav, can you make a video on Security: Oauth2, Jwt, OpenId, Saml, Basic, Digest, SSO, Social sign in. There are plenty on youtube individually but none has all these as a whole describing use cases and differentiating each other
POST means that you published a new form on the webcontent instead of making any query with data -> data. The REST is not SOAP! The REST is well done HTTP protocol.
Hey Gaurav, Nice explanation of good practices for API design and I totally agree with the thing nirupam pointed out . I see that many people down in comments of your videos often ask for content that you have previously completed. It is just a suggestion to start adding related videos' links to the description and calling them out through the video. You can also use overlay popups of youtube that other youtubers use extensively. Will just save you some redundancy in questions. Thanks
Thanks Avneesh! You are right, I can put them up better. They also need to make an effort though. If they can't Google search or read the video description before posting a comment, it's a hopeless cause of them :P
@@gkcs I am with you on that, just a little effort goes a long way for in depth understanding. Also depends a lot on one's curiosity and interest in said topic. But its mainly for your own convenience to reduce your effort of giving them a link everytime such a question arises.
Api design always starts from defining the resource url. Then you move towards defining the api spec and so forth... its called model first or api first approach.
good stuff gaurav, it was very well explained. the only thing is the speed. I had to bring it down to 0.75x and listen it. If you can adjust the tone fast and slow at times, it will go a long way
Gaurav, First of all, thanks for the wonderful videos you have put up for the show..... I request you to make a video on bulk action like adding million people to a group or sending mail to all existing users in one shot.... this is the feature we want to add to our product but not able to find an apt approach or sol for it......
7:05 a critical term is missed here, while "routing" is technically correct the appropriate naming is a "Resource". And the http verbs (GET, POST etc.) are called "Methods" rather than "functions". These terminologies are SUPER important from documentation and interview perspective. One more critical thing that you missed about HTTP requests is to talk about the architecture/pattern i.e. REST, it would be helpful to add a brief introduction of what REST means and what are ReST APIs. Otherwise good video.
@Gaurav one suggestion I have is and maybe it's a very important part of API design is that the objects which the API returns should be different from the actual backend objects. The reason this is very important is because if you decouple these 2 things, its easy to change something in the returned object without actually modifying the underlying business object. Also can you please add a video on how pagination is done?
@Gaurav, when you described the handling of Large Responses, you talked about 2 things [i] Pagination, [ii] Fragmentation. Shouldn't we consider HATEOAS also as a viable option? It would make API more connected and take off the burden of a large response. Also, in case if an API is designed to perform any Bulk Operation lets say import, then what should be the correct way to design it?
Just FYI, adding pagination to an API endpoint does not violate the "stateless" principle. The query is self-contained, and can be ran on any instance of the same service with the same results (assuming the data has not changed between requests).
@Gaurav, I really enjoyed this video and I feel like I learned a lot in short amount of time! Thank you for taking the time to create this valuable content!
I am electronics engineering student but learning both hardware and software is giving me more happiness rather than texting my crush (she never texts back)😂😂😂
Nice video but you haven’t mentioned few things like - speed/fast algorithm for the API, tactics to avoid frequent changes of the api signatures due to enhanced features, steps to be taken to avoid recompilation from client side when enhancement happens.
Hi Gaurav, thank you so much for this explanation! I have a question regarding setAdmins, what should the API response return if the one of the members of the group (admins parameter sent as a request) are already Admin or all the entire list of members of members are already Admins. Should we return 200 response? 10:08
Hello Gaurav, could u please give me a link about the API fragmentation please? Cuz i can't find one corresponding to what you described. Thank you in advance. I really like your videos :D
Hi @Gaurav,, Can you tell how it is different to make APIs for Web and for Mobile apps? Should we use mobile approach and assume "one size fits all " theory or should there be different API design approach for Web or Mobile ?
Couple of concerns i have in this video. In order to be understood by Business partners, the resource name should be a noun, instead of getAdmins, it should be Admins with GET operation. getAdmins should be a get operation not a POST.
Codechef ask Gaurav to delete interview video not because they want to release their version first but because they don't want Gaurav's interview video.
@gaurav please make a video on Docker that when it should be used. Which architecture suits docker the best. How nginx uwsgi and applications can be used inside multiple containers.
Atomicity means that operations must complete or fail as a whole unit. In case anyone was wondering.
That's proactiveness that most of the managers looks for
Also known as: the all-or-nothing property!
@Gaurav, we should not return list as a response to an API, and should return an object instead. that helps when we need to add a new variable in the response. In that case clients won't break.
Say in your example, in the future, if I wanted to add a new variable like "String resonseStatus" along with List, I can't really do that without making change in clients. But if I already returned an object, I could add any number of new variables to accommodate in the future.
That's a great point, thanks!
I don't totally agree with this approach. Yes, as an API definer, things will get easy for you. However, your consumer should still migrate to the new API version. By returning object as a response, you are saving yourself from changing the contract every time, however you are reducing the clarity of your contract and need to tell a lot in the documentation. I would prefer changing the API contract every time I make a backward incompatible change.
gud one, but I see Swagger is using list instead.....?
You make so much sense
I think there should not be any problem if we are returning JSON object or using GRPC
There are only 2 types of explanation for complex Computer Science concepts in this world:
- The one you had in universities which you don't understand sh*t.
- The one provided by an Indian engineer on TH-cam that would enlighten you in 15 min.
Thanks a lot man !
Hi Gaurav - just to clarify the following
1. APIs can expose only "public" methods ( not protected or private methods )
2. it is a good idea to minimize payloads sent in request objects via POST ( use GET instead ), and sending the routing information or action information in the JSON request payloads makes for dirty APIs.
the kind of clarity you have while explaining clears up the mess in my brain.. thanks gs
Happy to help!
The best way to design an API for designers is to start with the foundation. The foundation is where most developers get it wrong, from my experience. Everything starts with the why. A simple yet crucial question that one should ask. The why for doing something, triggers multiple conversations that span the user journey, business objective, data contract, data governance, compatibilities, and lastly the use case. Another really good thing I have noticed with a well-defined API is that it also makes you understand if the procurement of data is truly vital or not, thus, helping in prioritizing API A over B. If this API is only relevant to a very low amount of stakeholders, do I really want to design it? The rest are just bells and whistles.
So happy I found this channel!!!!! This is the next level interview prep material. I was focusing on the main, most important topics to study, more language based questions then I started getting System Level questions and didn't have a good explanation until I started watching these videos. The funny part is that I knew most this stuff, but I just drew a blank when asked. I hope to get through the playlist before my next interview!
Welcome aboard!
thank you so much!! 4 years later this is still so helpful! im glad i found your videos!
Thank you!
Good to see a বাঙালী teaching code 😊👍 subscribed 🤟🏻
I think RESTful APIs should work on Resource (in this case Group). We use certain HTTP verbs (e.g. GET, POST, PUT) to manipulate that resource.
So the URL of API should be like this:
GET /api/v1/groups//admins
Notice the resources are in pluralize form (groups, admins, employees). So if we want to get a details for specific admin, we can just append the adminId as well. (GET /api/v1/groups//admins/)
Optionally API could expect pagination, limit from URL GET parameters as well... like (?page_no=2&limit=20)
PS: Also most people use version in the beginning of URL. e.g. /api/v1/.
Exactly what i was thinking. Use nouns instead of verbs while designing Rest APIs. The actions are already defined by the types.
Also field filter reduces the payload in response, that way caller can decide what he needs.
Saved me from commenting. 2nd that absolutely.
ABSOLUTELY WELL SAID! THAT'S WHAT I NOTICED, IT SHOULD HAVE BEEN USED NOUN INSTEAD.
Just a small technical clarification.. the whole URL has components called URI - first part is the server address (mapped to a server somewhere using the IP address and port number), after that comes the individual context resources. Instead of model (the URI that comes after server address), let's say context for the actual resource. The next part(s) are the actual requested resources, which consist the name of the api method, and any parameters if present.
Some of the ideas are covered in "Clean Code" & "Clean Architecture", nice vid!
Thanks for explaining the application programmable interface. This content is helpful for understanding the structure of an API. Insightful and thought provoking😊
As a Database Developer, I see similar principles and terminology applies to API design as well. As they say, the more you know, the more things seem the same. Cool video bro.
I instantly subscribed you because how confident your voice is
Thank you!
Great video again. Good to see discussion on consistency here. Couple of comments. If the data is huge and if we are going to use IP fragmentation, then typically it is transparent to the application developer. Also it might have been interesting to get your perspective on handling partial success in the API, say for setAdmins, it set admins for the first 3, the 4 user id does not exist/not member of the group, how does it signal error. Thanks
Hi Hemanth, the response can be a complex object, in which there is a list of objects. Each object carrying information about each user. Using this way, we can give information on processing status of d admin.
{
AdminsProcessingStatus:
[
{ ISetASAdmin : true, ActionTaken : ExistingGroupMemberSetAsAdmin/AddedToGroupSndSetAsAdmin
}
]
}
Hi Gaurav, you are brilliant at explaining tech stuff. Absolutely love your videos. Really appreciate it! Thanks a ton.
Totally understood the thing with one sentence in the beginning
😁👍
Wow wow wow, your way of speech delivery is too fluent, I just love that
Even the design of this video is excellent -- like it's already at 1.5x Playback speed.
I went to speed it up, but then I realized that it was already perfect!
Thank you for this video, Guarav. Extremely helpful and I love your explanations. This has been a great resource as I prepare for an upcoming systems design interview.
Thanks Gaurav. 6:44 shouldn't it be called as "controller" rather "model" ?
Yeah I might have messed up the terms a bit :/
Awesome, I like it very much I appreciated. Wow the hint on fragmentation.
As per my understanding about API is: API is something which simply pulls out the data from the data source so that various applications can consume those APIs. Since our data source may or may not interact with other applications that's why we need to create an API. Here data source can be any databases or legacy systems like SAP.
I don't think that is very accurate. I could provide an API which returns a random number, or does a complex calculation using the input variables.
Hey gaurav, great seeing your videos, Wish someone taught me during my interview days, I remember some design questions I was asked - URL shortener, Web crawler and proximity servers(Yelp). You should definitely do these, I personally ask a few when I interview :P
Thank you!
In 39 seconds this boy explains "what is an api" in a way i wish my mentors had done.
KISS..
Loved the video... I really felt like i was talking to u and u were reading my thoughts as u were clearing all the doubts. Great One 👋👋
Regarding how to solve the 'number of admins' changed, you can subscribe to group chat changes.
You can subscribe to 'participants changed' event same as 'new message' event and etc. You must not query admins if you have them up-to date all the time.
This is what I was looking for! Thank you!
This guy is the real MVP!
If only there was a button for 100 likes!! I could relate to so many bad APIs written in the past. Now I know. I have been enlightened master! Thank You.
Cheers!
🎯 Key Takeaways for quick navigation:
00:28 📝 An API is a documented way for external consumers to interact with your code, specifying parameters, return types, and possible errors.
01:26 🚫 Misnaming APIs or adding unnecessary parameters can lead to confusion and poor API design.
03:26 ⚡ Additional parameters in API calls can be acceptable for optimization purposes, especially when performance is a critical concern.
05:31 🛡️ Design API errors based on common expectations and the responsibilities of your service. Avoid returning generic errors for all cases.
07:01 🌐 Plan the routing and actions of your API carefully to ensure clarity and prevent ambiguity in the API calls.
08:30 🔄 Avoid side effects in API calls; keep the actions focused on a single responsibility and ensure atomicity when necessary.
09:57 📦 Break down large responses using pagination or fragmentation to maintain efficiency and prevent overwhelming the network.
13:58 ⚙️ Consider data consistency needs; decide if perfect consistency is crucial or if slight delays or cached responses are acceptable for certain use cases.
Please make videos on Micro Services Architecture.
th-cam.com/video/qYhRvH9tJKw/w-d-xo.html
th-cam.com/video/vvhC64hQZMk/w-d-xo.html
Nice video, with excellent communication. Keep up the good work. Appreciated !!
Hi Gaurav,
First of all a big thanks to you sharing these neat and clean, content rich videos.
It helped me a lot to clear some of the key concepts which I use on day to day basis.
Finally I wish you all the best and I would say "YOU GOT A NEW SUBSCRIBER"!!!😊👍
an API is just a function...wow such a beautiful straightforward definition. I was confused since a week and everywhere they were just saying the things like "it is an interface to connect two software systems", "it is a set of rules and protocols" etc. but no was saying actually explaining it in terms of programming.
But Gaurav sir, you just helped me to get through its heart as what it actually is at its core. Thank you so much for relieving my week's pain and confusion.
Since it is a function that only care about "what" that is, it hides the abstractions so I'm assuming that it is an higher level function which calls the specific part/module of the system to get the work done and once the tasks is done, it compose the response (generally as an object) and return it.
api isn't a function but an interface (at least not in java). They're like contracts written for achieving abstraction similar to abstract classes but their purpose is generally for abstracting functions. Read about interfaces to understand.
Great video. Please keep posting such videos.
Hi Gaurav, can you make a video on Security: Oauth2, Jwt, OpenId, Saml, Basic, Digest, SSO, Social sign in. There are plenty on youtube individually but none has all these as a whole describing use cases and differentiating each other
Sometime in future :)
Great video man. Is there more product design (API Design) videos out there? I wasn't able to find much.
Thanks Gaurav, you’re the real deal 👍
😁
Real value education ! Thanks bro !
Really helpful Gaurav! Thanks
A very effective one.
Thanks Mr. Gaurav.
POST means that you published a new form on the webcontent instead of making any query with data -> data. The REST is not SOAP! The REST is well done HTTP protocol.
Thank you my friend a student from iraq
Thank you!
Hey Gaurav,
Nice explanation of good practices for API design and I totally agree with the thing nirupam pointed out . I see that many people down in comments of your videos often ask for content that you have previously completed. It is just a suggestion to start adding related videos' links to the description and calling them out through the video. You can also use overlay popups of youtube that other youtubers use extensively. Will just save you some redundancy in questions.
Thanks
Thanks Avneesh! You are right, I can put them up better.
They also need to make an effort though. If they can't Google search or read the video description before posting a comment, it's a hopeless cause of them :P
@@gkcs I am with you on that, just a little effort goes a long way for in depth understanding. Also depends a lot on one's curiosity and interest in said topic. But its mainly for your own convenience to reduce your effort of giving them a link everytime such a question arises.
@@sdfg204 True, thanks!
Api design always starts from defining the resource url. Then you move towards defining the api spec and so forth... its called model first or api first approach.
As always, good explanation!
good stuff gaurav, it was very well explained. the only thing is the speed. I had to bring it down to 0.75x and listen it. If you can adjust the tone fast and slow at times, it will go a long way
Bro you are too good...!!! Keep it up.. Will be waiting for you further videos..
Naming is important.
So is competitive programming 👍🏻👍🏻👍🏻👍🏻
Gaurav, First of all, thanks for the wonderful videos you have put up for the show..... I request you to make a video on bulk action like adding million people to a group or sending mail to all existing users in one shot.... this is the feature we want to add to our product but not able to find an apt approach or sol for it......
7:05 a critical term is missed here, while "routing" is technically correct the appropriate naming is a "Resource". And the http verbs (GET, POST etc.) are called "Methods" rather than "functions". These terminologies are SUPER important from documentation and interview perspective. One more critical thing that you missed about HTTP requests is to talk about the architecture/pattern i.e. REST, it would be helpful to add a brief introduction of what REST means and what are ReST APIs. Otherwise good video.
I would like to echo the same thing. Since 2013
Please make a video on good coding style and some common bad programming practises.
Check out the tic tac toe one
Wonderful in details API design !! Would have been great to include Bulk APIs on large dataset as well.
Thanks!
I'll try and talk about this in a future video 😁
@Gaurav one suggestion I have is and maybe it's a very important part of API design is that the objects which the API returns should be different from the actual backend objects. The reason this is very important is because if you decouple these 2 things, its easy to change something in the returned object without actually modifying the underlying business object. Also can you please add a video on how pagination is done?
That's a good idea, something I have seen in my experience :)
And I'll get to pagination in future videos :)
Can data transfer objects (DTOs) be used for this decoupling of objects. In C# context
Versioning is a must. So it conforming to HTTP methods.
@Gaurav, when you described the handling of Large Responses, you talked about 2 things [i] Pagination, [ii] Fragmentation. Shouldn't we consider HATEOAS also as a viable option? It would make API more connected and take off the burden of a large response.
Also, in case if an API is designed to perform any Bulk Operation lets say import, then what should be the correct way to design it?
Correct me if i am wrong but pagination is the thing that comes with hateoas right?
I'm sure Gaurav can easily transition into a formal teaching career if he wants oneday
This aged well.
But in formal teaching the most focus is on theory and completing the syllabus ;)
*Phenomenal video!*
Thanks.. searching a lot for a similar thing from a long time
Just FYI, adding pagination to an API endpoint does not violate the "stateless" principle. The query is self-contained, and can be ran on any instance of the same service with the same results (assuming the data has not changed between requests).
That's true, and I did know this when mentioning it. I wanted people to think over it :P
You are a great teacher... I don't know where you work, but if ever Interested in Amazon, let me know and I'll see what I can do for you
Thank you! I currently work at Uber :)
This is pure gem ❤
@Gaurav, I really enjoyed this video and I feel like I learned a lot in short amount of time! Thank you for taking the time to create this valuable content!
Thank you 😁
I usually speed up the video speed on TH-cam, but this is the first video where I had to slow it down.
I'll take that as a compliment :p
@@gkcs yes i meant in a positive way , so many, so good info here.
Really clear explanation - thank you! :)
I am electronics engineering student but learning both hardware and software is giving me more happiness rather than texting my crush (she never texts back)😂😂😂
I am...happy for you :P
Nicely explained helpful video ❤️
For breaking the record, starting to watch you again, full fledge! :D
Welcome back!
Your video is very helpful. Keep posting good content.
The sound quality has improved a lot, are you using a new mic?
Yup!
Thanks for the great vid!
Well done Gaurav... Your almost there
Where am I? 😛
Still breaking through the barriers
Still breaking through complications
swaaad he aa gya video dekh k
Nice video but you haven’t mentioned few things like - speed/fast algorithm for the API, tactics to avoid frequent changes of the api signatures due to enhanced features, steps to be taken to avoid recompilation from client side when enhancement happens.
Let me mention them all now then:
Don't make breaking changes 😛
@Gaurav, it was a nice & Brief Explanation
Explained well....Also It would be great if you share some real time test case using any Rabbit MQ kind or Messaging platform!
Maybe next time 😁
@@gkcs Thnak You 😊
Love your videos. Just an idea, Would Secure REST API be a good Idea for a video ?
Great video Sir as always! Thank you so much.
Hi Gaurav, thank you so much for this explanation! I have a question regarding setAdmins, what should the API response return if the one of the members of the group (admins parameter sent as a request) are already Admin or all the entire list of members of members are already Admins. Should we return 200 response? 10:08
If it's possible to add subtitles... then its good bro, It's very helpful
Bro, do you live in India or the US? . I am just fascinated by level of knowledge you have.
India 😁
great video. very useful information.
Nice explanation mate
Hello Gaurav, could u please give me a link about the API fragmentation please? Cuz i can't find one corresponding to what you described. Thank you in advance. I really like your videos :D
Very well explained. Can you also have session to cover various types of API?
Hi @Gaurav,, Can you tell how it is different to make APIs for Web and for Mobile apps? Should we use mobile approach and assume "one size fits all " theory or should there be different API design approach for Web or Mobile ?
Couple of concerns i have in this video. In order to be understood by Business partners, the resource name should be a noun, instead of getAdmins, it should be Admins with GET operation. getAdmins should be a get operation not a POST.
I did mention this in the video :)
Hi Gaurav, Can you please explain the fragmentation part . May be in a separate video
You are very motivating. Best of luck for more challenges
great explanation even though i know all of it...great going .....learnt some too
The one we've been waiting for
excellent as always
Codechef ask Gaurav to delete interview video not because they want to release their version first but because they don't want Gaurav's interview video.
what do you mean? when did this happen?
Is there any torrent link/Magnet URL for that video?
Thank you very much for the tutorial. Could you please add subtitle as well?
@gaurav please make a video on Docker that when it should be used. Which architecture suits docker the best. How nginx uwsgi and applications can be used inside multiple containers.
I'll make one on containers too :)
@@gkcs waiting for that video to come😍
Another great lesson 🙏
Thanks 😊
You are awesome mate!!!!Love your videos
Thanks!