API Design Deep Dive - Unleashing the Potential of API Design Activities

แชร์
ฝัง
  • เผยแพร่เมื่อ 24 ก.ย. 2024
  • This video explains and discusses every possible step involved during the API Design Stage and clearly distinguishes the activities from Architecture Phase. This video also explains what NOT to do during the design phase that are not appropriate to Design.
    These are common principles and guidelines and not Thumb Rules. The Design of the Specific API or Specific Feature need to be flexible for the specific use-case scenarios depending on the exact requirements and Architecture Goals.
    If there are any doubts, questions or clarifications on the Architecture or related topics, please feel free to add your questions in the comments section, I will try to clarify.
  • วิทยาศาสตร์และเทคโนโลยี

ความคิดเห็น • 12

  • @nishaddheeraj2
    @nishaddheeraj2 4 ปีที่แล้ว

    Thank you!! your each and every video is informative and excellent.

  • @EnRouteMentor
    @EnRouteMentor 4 ปีที่แล้ว

    very informative video dear thanks alot for sharing the such a great knowledge.

  • @rajhirs1440
    @rajhirs1440 4 ปีที่แล้ว

    Thanks, Siva for API design readiness tutorial. let me tell you that right now no one giving video or training on mulesoft they way you are covering very high level and important area of mulesoft with very good details and very clear audio, even nothing available on google. i would suggest make detail training videos of Mule dev. and Architecture level two separate courses and upload it on udemy or your other platform. You will be on top in mulesoft training market and it will help lot of people as well as you.
    Request : can you please make video on framework when we have 100s of API maintaining within a project as well as migration from Mule 3 to 4 and how to convert existing java API project into Mule project. i know this is lot of things and it will take time to make videos.

  • @chayadesignstudio2028
    @chayadesignstudio2028 4 ปีที่แล้ว

    thank you so much Siva nice explanation each and everything. you will show us the implementation Part also.

  • @sanjaybharatiya5074
    @sanjaybharatiya5074 3 ปีที่แล้ว

    What do you mean by a feature? Does it map to feature in Agile? Or implementation feature like create employee is one feature, update employee is another feature, delete order is another feature, etc.

  • @michaelj1743
    @michaelj1743 4 ปีที่แล้ว

    thank you siva!!!!!!!

  • @dineshbabu4919
    @dineshbabu4919 4 ปีที่แล้ว

    Excellent explanation Sir:) thank you

  • @thedeveloper2513
    @thedeveloper2513 4 ปีที่แล้ว

    Hi Siva great video. One question, on 21:22..number 7 are you saying if we create a System API where it will perform GET, PUT and POST methods, then the three methods should be different APIs each doing specific methods? Or they should be part of one API doing it all?

    • @sivathankamanee-channel
      @sivathankamanee-channel  4 ปีที่แล้ว +1

      Hi thanks again for the appreciation. The idea is one feature per API not just one method. For example - 'Maintain Employees' will be one API. This is one API that had multiple resource path and methods like GET PUT POST, etc. This API must deal work all employee related operations like new employee update existing explore retire employee exit employee etc.

    • @thedeveloper2513
      @thedeveloper2513 4 ปีที่แล้ว

      @@sivathankamanee-channel Thanks, yeah now it makes sense.

    • @sanjaybharatiya5074
      @sanjaybharatiya5074 3 ปีที่แล้ว

      @@sivathankamanee-channel Many thanks for posting these very informative videos. These real world scenarios help us to understand things much better. I have a use case for which I want to understand the API design approach in different layers.
      Suppose we are developing APIs for employee management where we can create an employee, get an employee profile and update an employee details.
      In the backend there are two systems say a HRMS (HR Management System) and a Financial System (FMS). For creating an employee we need to call 1 API of HRMS and 2 APIs of FMS.
      For getting employee profile we just need to call 1 API from HRMS. For updating an employee we need to call 1 HRMS API and 2 FMS API.
      Employee management (create, get and update) can be done from both a web app or mobile App but both use same data format and model
      How should be design the APIs in different layers? For example shall we create 1 System API for HRMS (system-hrms-api) and 1 System API for FMS (system-fms-api). And call all the HRMS APIs from system-hrms-api and all FMS APIs from system-fms-api.
      Or shall we create 3 System APIs for HRMS and 4 System APIs for FMS?
      Shall we treat create, get and update employee as separate features or one feature (just one resource = employee)?