সিস্টেম ডিজাইন চিট শীট: API শৈলী - REST, GraphQL, WebSocket, Webhook, RPC/gRPC, SOAP

এটি একটি ধারাবাহিক প্রবন্ধের ধারাবাহিকতা যেখানে আমি সংক্ষেপে সিস্টেম আর্কিটেকচার ডিজাইনের একটি নির্দিষ্ট বিষয়ের মূল বিষয়গুলি কভার করি৷ প্রথম নিবন্ধ এখানে পড়া যাবে

API আর্কিটেকচার নিয়ম, প্রোটোকল এবং সরঞ্জামগুলির সেটকে বোঝায় যা নির্দেশ করে যে কীভাবে সফ্টওয়্যার উপাদানগুলি ইন্টারঅ্যাক্ট করা উচিত। একটি API এর আর্কিটেকচার শুধুমাত্র যোগাযোগের সুবিধার জন্য নয়; এটি নিশ্চিত করা যে এই যোগাযোগটি দক্ষ, সুরক্ষিত এবং মাপযোগ্য।

একটি ভাল-পরিকল্পিত API আর্কিটেকচার একটি সিস্টেমের কার্যকারিতা উল্লেখযোগ্যভাবে উন্নত করতে পারে, যখন একটি খারাপভাবে ডিজাইন করা বাধা, নিরাপত্তা দুর্বলতা এবং রক্ষণাবেক্ষণের দুঃস্বপ্নের দিকে নিয়ে যেতে পারে।

API আর্কিটেকচারের বিভিন্ন শৈলী

সবচেয়ে সাধারণ API ডিজাইন শৈলী:

1. REST (রিপ্রেজেন্টেশনাল স্টেট ট্রান্সফার) হল সবচেয়ে বেশি ব্যবহৃত স্টাইল যা স্ট্যান্ডার্ড পদ্ধতি এবং HTTP প্রোটোকল ব্যবহার করে। এটি রাষ্ট্রহীনতা, ক্লায়েন্ট-সার্ভার আর্কিটেকচার এবং ক্যাশেবিলিটির মত নীতির উপর ভিত্তি করে। এটি প্রায়শই ফ্রন্ট-এন্ড ক্লায়েন্ট এবং ব্যাক-এন্ড পরিষেবাগুলির মধ্যে ব্যবহৃত হয়।

   
   

2. GraphQL হল API-এর জন্য একটি ক্যোয়ারী ভাষা। REST এর বিপরীতে, যা প্রতিটি সংস্থানের জন্য একটি নির্দিষ্ট সেটের শেষ পয়েন্ট প্রকাশ করে, GraphQL ক্লায়েন্টদের তাদের প্রয়োজনীয় ডেটার অনুরোধ করতে দেয়, ওভার-ফেচিং হ্রাস করে।

   
   

3. WebSocket হল একটি প্রোটোকল যা TCP এর মাধ্যমে দ্বিমুখী যোগাযোগের অনুমতি দেয়। ক্লায়েন্টরা ব্যাক-এন্ড সিস্টেম থেকে রিয়েল-টাইম আপডেট পেতে ওয়েব সকেট ব্যবহার করে।

   
   

4. ওয়েবহুক হল এমন একটি প্রক্রিয়া যা একটি সিস্টেমকে রিয়েল-টাইমে নির্দিষ্ট ইভেন্ট সম্পর্কে অন্য সিস্টেমকে অবহিত করার অনুমতি দেয়। এটি একটি ব্যবহারকারী-সংজ্ঞায়িত HTTP কলব্যাক।

   
   

5. RPC (gRPC) হল একটি প্রোটোকল যা একটি পরিষেবা একটি নেটওয়ার্কের অন্য কম্পিউটারে অবস্থিত একটি পরিষেবা থেকে একটি পদ্ধতি/পদ্ধতির অনুরোধ করতে ব্যবহার করতে পারে। সাধারণত, এটি কম লেটেন্সি, উচ্চ-গতির যোগাযোগের জন্য ডিজাইন করা হয়েছে।

   
   

6. SOAP হল ওয়েব পরিষেবা বাস্তবায়নের জন্য কাঠামোগত তথ্য বিনিময়ের জন্য একটি প্রোটোকল। এটি XML-এর উপর নির্ভর করে এবং এর দৃঢ়তা এবং সুরক্ষা বৈশিষ্ট্যগুলির জন্য পরিচিত, বর্তমানে একটি উত্তরাধিকার প্রোটোকল হিসাবে বিবেচিত হয়।

আসুন প্রতিটি প্রোটোকলকে তাদের সমস্ত সুবিধা, অসুবিধা এবং ব্যবহারের ক্ষেত্রে আলাদাভাবে দেখি।

বিশ্রাম

REST হল একটি স্থাপত্য শৈলী যা সাধারণ নিয়মাবলী এবং প্রোটোকল ব্যবহার করে, এটি বোঝা এবং বাস্তবায়ন করা সহজ করে তোলে। এর রাষ্ট্রহীন প্রকৃতি এবং স্ট্যান্ডার্ড HTTP পদ্ধতির ব্যবহার এটিকে ওয়েব-ভিত্তিক API তৈরির জন্য একটি জনপ্রিয় পছন্দ করে তোলে।

যদিও REST দীর্ঘকাল ধরে এপিআই তৈরির জন্য ডি ফ্যাক্টো স্ট্যান্ডার্ড, গ্রাফকিউএল-এর মতো অন্যান্য শৈলী আবির্ভূত হয়েছে, তথ্য অনুসন্ধান এবং ম্যানিপুলেট করার জন্য বিভিন্ন দৃষ্টান্ত প্রদান করে।

বিন্যাস : XML, JSON, HTML, প্লেইন টেক্সট

পরিবহন প্রোটোকল : HTTP/HTTPS

মূল ধারণা এবং বৈশিষ্ট্য

• সম্পদ : REST-এ, সবকিছুই একটি সম্পদ। রিসোর্স হল একটি অবজেক্ট যার একটি ধরন, সংশ্লিষ্ট ডেটা, অন্যান্য রিসোর্সের সাথে সম্পর্ক এবং এটির উপর কাজ করে এমন পদ্ধতির একটি সেট। সংস্থানগুলি তাদের URI (সাধারণত একটি URL) দ্বারা চিহ্নিত করা হয়।

  
  

• CRUD অপারেশন : REST পরিষেবাগুলি প্রায়শই সংস্থানগুলিতে CRUD (তৈরি করুন, পড়ুন, আপডেট করুন, মুছুন) অপারেশনগুলিতে সরাসরি ম্যাপ করে।

  
  

• HTTP পদ্ধতি : REST সিস্টেমগুলি স্ট্যান্ডার্ড HTTP পদ্ধতি ব্যবহার করে:

  • GET: একটি সম্পদ পুনরুদ্ধার করুন।

  • পোস্ট: একটি নতুন সংস্থান তৈরি করুন।

  • PUT/PATCH: একটি বিদ্যমান সম্পদ আপডেট করুন।

  • মুছুন: একটি সংস্থান সরান।

    
    

• স্ট্যাটাস কোড : REST API গুলি একটি API অনুরোধের সফলতা বা ব্যর্থতা নির্দেশ করতে স্ট্যান্ডার্ড HTTP স্ট্যাটাস কোড ব্যবহার করে:

  • 2xx - স্বীকৃতি এবং সাফল্য
    • 200 - ঠিক আছে
    • 201 - তৈরি
    • 202 - গৃহীত
  • 3xx - পুনঃনির্দেশ
    • 301 - স্থায়ীভাবে সরানো হয়েছে
    • 302 - পাওয়া গেছে
    • 303 - অন্যান্য দেখুন
  • 4xx - ক্লায়েন্ট ত্রুটি
    • 400 খারাপ অনুরোধ
    • 401 - অননুমোদিত
    • 403 নিষিদ্ধ
    • 404 পাওয়া যায়নি
    • 405 - পদ্ধতি অনুমোদিত নয়
  • 5xx - সার্ভার ত্রুটি

    • 500 অভ্যন্তরীণ সার্ভার সমস্যা

    • 501 - বাস্তবায়িত হয়নি

    • 502 - খারাপ গেটওয়ে

    • 503 - পরিষেবা অনুপলব্ধ৷

    • 504 - গেটওয়ে টাইমআউট

      
      

• স্টেটলেস : ক্লায়েন্ট থেকে সার্ভারের প্রতিটি অনুরোধে অনুরোধটি বুঝতে এবং প্রক্রিয়া করার জন্য প্রয়োজনীয় সমস্ত তথ্য থাকতে হবে। সার্ভারের অনুরোধের মধ্যে ক্লায়েন্টের অবস্থা সম্পর্কে কিছু সংরক্ষণ করা উচিত নয়।

  
  

• ক্লায়েন্ট-সার্ভার : REST ক্লায়েন্ট-সার্ভার মডেলের উপর ভিত্তি করে। ক্লায়েন্ট ব্যবহারকারীর ইন্টারফেস এবং অভিজ্ঞতার জন্য দায়ী, যখন সার্ভার অনুরোধ প্রক্রিয়াকরণ, ব্যবসায়িক যুক্তি পরিচালনা এবং ডেটা সংরক্ষণের জন্য দায়ী।

  
  

• ক্যাশেযোগ্য : সার্ভার থেকে প্রতিক্রিয়া ক্লায়েন্ট দ্বারা ক্যাশে করা যেতে পারে। একটি প্রতিক্রিয়া ক্যাশেযোগ্য কিনা সার্ভার অবশ্যই নির্দেশ করবে।

  
  

• স্তরযুক্ত সিস্টেম : একটি ক্লায়েন্ট সাধারণত বলতে পারে না যে এটি সরাসরি শেষ সার্ভারের সাথে সংযুক্ত নাকি মধ্যস্থতাকারী। মধ্যস্থতাকারী সার্ভারগুলি লোড ব্যালেন্সিং সক্ষম করে এবং ভাগ করা ক্যাশে প্রদান করে সিস্টেমের মাপযোগ্যতা উন্নত করতে পারে।

  
  

• HATEOAS: হাইপারমিডিয়া অ্যাজ দ্য ইঞ্জিন অফ অ্যাপ্লিকেশান স্ট্যাট হল একটি REST ওয়েব পরিষেবা নীতি যা ক্লায়েন্টদের একটি ওয়েব অ্যাপ্লিকেশানের সাথে যোগাযোগ করতে এবং নেভিগেট করতে সক্ষম করে সম্পূর্ণরূপে তার প্রতিক্রিয়াগুলিতে সার্ভার দ্বারা গতিশীলভাবে সরবরাহ করা হাইপারমিডিয়ার উপর ভিত্তি করে, আলগা সংযোগ এবং আবিষ্কারযোগ্যতা প্রচার করে৷

ব্যবহারের ক্ষেত্রে

• ওয়েব পরিষেবা : অনেক ওয়েব পরিষেবা REST API-এর মাধ্যমে তাদের কার্যকারিতা প্রকাশ করে, যা তৃতীয় পক্ষের বিকাশকারীদের তাদের পরিষেবাগুলিকে একীভূত করতে এবং প্রসারিত করতে দেয়৷

• মোবাইল অ্যাপ্লিকেশন : মোবাইল অ্যাপ্লিকেশনগুলি প্রায়ই ডেটা আনতে এবং পাঠাতে REST API ব্যবহার করে ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করে।

• একক পৃষ্ঠা অ্যাপ্লিকেশন (এসপিএ) : সম্পূর্ণ পৃষ্ঠা রিফ্রেশের প্রয়োজন ছাড়াই গতিশীলভাবে সামগ্রী লোড করতে এসপিএগুলি REST API ব্যবহার করে।

• সিস্টেমের মধ্যে ইন্টিগ্রেশন: একটি প্রতিষ্ঠানের মধ্যে সিস্টেমগুলি REST API ব্যবহার করে তথ্য আদান-প্রদান করতে পারে।

উদাহরণ

অনুরোধ

"/user/42" পান

প্রতিক্রিয়া

 { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } }

গ্রাফকিউএল

গ্রাফকিউএল এপিআই তৈরির জন্য আরও নমনীয়, শক্তিশালী এবং দক্ষ পদ্ধতির অফার করে, বিশেষ করে জটিল সিস্টেমে বা যখন ফ্রন্টএন্ডের উচ্চ নমনীয়তার প্রয়োজন হয়। এটি সার্ভার থেকে ক্লায়েন্টের কাছে কিছু দায়িত্ব স্থানান্তর করে, ক্লায়েন্টকে তার ডেটা প্রয়োজনীয়তা নির্দিষ্ট করার অনুমতি দেয়।

যদিও এটি সমস্ত পরিস্থিতিতে REST-এর প্রতিস্থাপন নয়, এটি অনেক পরিস্থিতিতে একটি বাধ্যতামূলক বিকল্প প্রস্তাব করে, বিশেষ করে যখন অ্যাপ্লিকেশনগুলি আরও নেটওয়ার্ক এবং বিতরণ করা হয়।

বিন্যাস : JSON

পরিবহন প্রোটোকল : HTTP/HTTPS

মূল ধারণা এবং বৈশিষ্ট্য

• API-এর জন্য ক্যোয়ারী ল্যাঙ্গুয়েজ : এটি ক্লায়েন্টদের তাদের প্রয়োজনীয় ডেটার অনুরোধ করতে দেয়, যার ফলে একটি অনুরোধে সমস্ত প্রয়োজনীয় তথ্য পাওয়া সম্ভব হয়।

• টাইপ সিস্টেম : গ্রাফকিউএল এপিআইগুলি প্রকার এবং ক্ষেত্রের পরিপ্রেক্ষিতে সংগঠিত হয়, শেষবিন্দু নয়। এটি একটি API এর ক্ষমতা নির্ধারণ করতে একটি শক্তিশালী টাইপ সিস্টেম ব্যবহার করে। গ্রাফকিউএল স্কিমা ডেফিনিশন ল্যাঙ্গুয়েজ (এসডিএল) ব্যবহার করে একটি এপিআই-এ উন্মোচিত সমস্ত প্রকার একটি স্কিমাতে লেখা হয়।

• একক এন্ডপয়েন্ট : REST-এর বিপরীতে, যেখানে আপনার কাছে বিভিন্ন সম্পদের জন্য একাধিক এন্ডপয়েন্ট থাকতে পারে, GraphQL-এ, আপনি সাধারণত একটি একক এন্ডপয়েন্ট উন্মোচন করেন যা পরিষেবার ক্ষমতার সম্পূর্ণ সেট প্রকাশ করে।

• সমাধানকারী : সার্ভারের দিকে, সমাধানকারীরা একটি প্রশ্নে বর্ণিত ডেটা সংগ্রহ করে।

• সাবস্ক্রিপশন সহ রিয়েল-টাইম আপডেট : শুধুমাত্র ডেটা অনুসন্ধানের বাইরে, গ্রাফকিউএল সাবস্ক্রিপশন ব্যবহার করে রিয়েল-টাইম আপডেটের জন্য অন্তর্নির্মিত সমর্থন অন্তর্ভুক্ত করে।

• অন্তর্মুখী : একটি GraphQL সার্ভার যে ধরনের সমর্থন করে তার জন্য জিজ্ঞাসা করা যেতে পারে। এটি ক্লায়েন্ট এবং সার্ভারের মধ্যে একটি শক্তিশালী চুক্তি তৈরি করে, যা টুলিং এবং আরও ভাল বৈধতার অনুমতি দেয়।

ব্যবহারের ক্ষেত্রে

• নমনীয় ফ্রন্টেন্ডস : গুরুত্বপূর্ণ ব্যান্ডউইথ সহ অ্যাপ্লিকেশনগুলির জন্য (বিশেষত মোবাইল), আপনি সার্ভার থেকে আনা ডেটা কমিয়ে আনতে চান।

• অ্যাগ্রিগেটিং মাইক্রোসার্ভিসেস : আপনার একাধিক মাইক্রোসার্ভিস থাকলে এই পরিষেবাগুলি থেকে ডেটা একত্রিত করতে একটি গ্রাফকিউএল স্তর চালু করা যেতে পারে।

• রিয়েল-টাইম অ্যাপ্লিকেশন : এর সাবস্ক্রিপশন সিস্টেমের সাথে, গ্রাফকিউএল এমন অ্যাপ্লিকেশনগুলির জন্য একটি চমৎকার ফিট হতে পারে যেগুলির জন্য রিয়েল-টাইম ডেটা প্রয়োজন, যেমন চ্যাট অ্যাপ্লিকেশন, লাইভ স্পোর্টস আপডেট ইত্যাদি।

• সংস্করণ-মুক্ত API : REST-এর সাথে, পরিবর্তনগুলি চালু হওয়ার পরে আপনাকে প্রায়শই আপনার APIগুলির সংস্করণ করতে হবে। GraphQL এর সাথে, ক্লায়েন্টরা শুধুমাত্র প্রয়োজনীয় ডেটার জন্য অনুরোধ করে, তাই নতুন ক্ষেত্র বা ধরন যোগ করলে তা ভাঙা পরিবর্তন তৈরি করে না।

উদাহরণ

অনুরোধ

"/graphql?query=user(id:42){ নামের ভূমিকা { id name } }" পান

প্রতিক্রিয়া

 { "data": { "user": { "id": 42, "name": "Alex", "role": { "id": 1, "name": "admin" } } } }

ওয়েবসকেট

WebSockets একটি একক, দীর্ঘস্থায়ী সংযোগের মাধ্যমে একটি পূর্ণ-দ্বৈত যোগাযোগ চ্যানেল সরবরাহ করে, যা একটি ক্লায়েন্ট এবং একটি সার্ভারের মধ্যে রিয়েল-টাইম ডেটা বিনিময়ের অনুমতি দেয়। এটি ইন্টারেক্টিভ এবং উচ্চ-পারফরম্যান্স ওয়েব অ্যাপ্লিকেশনের জন্য এটি আদর্শ করে তোলে।

বিন্যাস : বাইনারি

পরিবহন প্রোটোকল : TCP

মূল ধারণা এবং বৈশিষ্ট্য

• ক্রমাগত সংযোগ : প্রথাগত অনুরোধ-প্রতিক্রিয়া মডেলের বিপরীতে, WebSockets একটি পূর্ণ-দ্বৈত যোগাযোগের চ্যানেল প্রদান করে যা খোলা থাকে, রিয়েল-টাইম ডেটা বিনিময়ের অনুমতি দেয়।

• হ্যান্ডশেক আপগ্রেড করুন : ওয়েবসকেটগুলি একটি HTTP অনুরোধ হিসাবে শুরু হয়, যা সার্ভার সমর্থন করলে একটি ওয়েবসকেট সংযোগে আপগ্রেড করা হয়। এটি `আপগ্রেড` হেডারের মাধ্যমে করা হয়।

• ফ্রেম : একবার সংযোগ স্থাপন করা হলে, তথ্য ফ্রেম হিসাবে প্রেরণ করা হয়। এই ফ্রেমের মাধ্যমে পাঠ্য এবং বাইনারি ডেটা উভয়ই পাঠানো যেতে পারে।

• কম লেটেন্সি : ওয়েবসকেট প্রতিটি এক্সচেঞ্জের জন্য একটি নতুন সংযোগ খোলার ওভারহেড ছাড়াই ক্লায়েন্ট এবং সার্ভারের মধ্যে সরাসরি যোগাযোগের অনুমতি দেয়। এর ফলে দ্রুত তথ্য বিনিময় হয়।

• দ্বিমুখী : ক্লায়েন্ট এবং সার্ভার উভয়ই একে অপরকে স্বাধীনভাবে বার্তা পাঠাতে পারে।

• কম ওভারহেড : প্রাথমিক সংযোগের পরে, ডেটা ফ্রেমের পাঠাতে কম বাইট প্রয়োজন, যা বারবার HTTP সংযোগ স্থাপনের চেয়ে কম ওভারহেড এবং ভাল কর্মক্ষমতার দিকে পরিচালিত করে।

• প্রোটোকল এবং এক্সটেনশন : ওয়েবসকেটগুলি সাবপ্রোটোকল এবং এক্সটেনশনগুলিকে সমর্থন করে, যা বেস ওয়েবসকেট প্রোটোকলের উপরে প্রমিত এবং কাস্টম প্রোটোকলের অনুমতি দেয়।

ব্যবহারের ক্ষেত্রে

• অনলাইন গেমিং : রিয়েল-টাইম মাল্টিপ্লেয়ার গেম যেখানে খেলোয়াড়দের কর্ম অবিলম্বে অন্যান্য খেলোয়াড়দের প্রতিফলিত হতে হবে।

• সহযোগিতামূলক সরঞ্জাম : Google ডক্সের মতো অ্যাপ্লিকেশন, যেখানে একাধিক ব্যবহারকারী একই সাথে একটি নথি সম্পাদনা করতে পারে এবং রিয়েল-টাইমে একে অপরের পরিবর্তন দেখতে পারে।

• আর্থিক অ্যাপ্লিকেশন : স্টক ট্রেডিং প্ল্যাটফর্ম যেখানে স্টক মূল্য রিয়েল-টাইমে আপডেট করা প্রয়োজন।

• বিজ্ঞপ্তি : যেকোন অ্যাপ্লিকেশন যেখানে ব্যবহারকারীদের রিয়েল-টাইম বিজ্ঞপ্তি পেতে হবে, যেমন সোশ্যাল মিডিয়া প্ল্যাটফর্ম বা মেসেজিং অ্যাপ।

• লাইভ ফিড : নিউজ ওয়েবসাইট বা সোশ্যাল মিডিয়া প্ল্যাটফর্ম যেখানে ব্যবহারকারীদের কাছে নতুন পোস্ট বা আপডেট লাইভ স্ট্রিম করা হয়।

উদাহরণ

অনুরোধ

"ws://site:8181" পান

প্রতিক্রিয়া

HTTP/1.1 101 স্যুইচিং প্রোটোকল

ওয়েবহুক

ওয়েবহুক হল একটি ব্যবহারকারী-সংজ্ঞায়িত HTTP কলব্যাক যা নির্দিষ্ট ওয়েব অ্যাপ্লিকেশন ইভেন্ট দ্বারা ট্রিগার হয়, যা বিভিন্ন সিস্টেমের মধ্যে রিয়েল-টাইম ডেটা আপডেট এবং একীকরণের অনুমতি দেয়।

বিন্যাস : XML, JSON, প্লেইন টেক্সট

পরিবহন প্রোটোকল : HTTP/HTTPS

মূল ধারণা এবং বৈশিষ্ট্য

• ইভেন্ট-চালিত : ওয়েবহুকগুলি সাধারণত একটি ইভেন্ট ঘটেছে তা বোঝাতে ব্যবহৃত হয়। নিয়মিত ব্যবধানে ডেটা অনুরোধ করার পরিবর্তে, ওয়েবহুকগুলি যেমন ঘটবে তেমন ডেটা সরবরাহ করে, প্রথাগত অনুরোধ-প্রতিক্রিয়া মডেলটিকে তার মাথায় ঘুরিয়ে দেয়।

• কলব্যাক মেকানিজম : ওয়েবহুক মূলত একটি ব্যবহারকারী-সংজ্ঞায়িত কলব্যাক প্রক্রিয়া। যখন একটি নির্দিষ্ট ঘটনা ঘটে, উৎস সাইটটি লক্ষ্য সাইট দ্বারা প্রদত্ত URI-তে একটি HTTP কলব্যাক করে, যা তারপর একটি নির্দিষ্ট ব্যবস্থা গ্রহণ করবে।

• পেলোড : যখন ওয়েবহুক ট্রিগার হয়, উৎস সাইটটি লক্ষ্য সাইটে ডেটা (পেলোড) পাঠাবে। এই ডেটা সাধারণত JSON বা XML আকারে থাকে।

• রিয়েল-টাইম : ওয়েবহুকগুলি অ্যাপ্লিকেশনগুলিকে রিয়েল-টাইম ডেটা পেতে দেয়, তাদের অত্যন্ত প্রতিক্রিয়াশীল করে তোলে।

• কাস্টমাইজযোগ্য : ব্যবহারকারী বা ডেভেলপাররা সাধারণত কোন নির্দিষ্ট ইভেন্ট সম্পর্কে অবহিত করতে চান তা নির্ধারণ করতে পারেন।

• নিরাপত্তা : যেহেতু ওয়েবহুক ব্যবহারকারী-সংজ্ঞায়িত HTTP এন্ডপয়েন্টে কলব্যাক করা জড়িত, তাই তারা নিরাপত্তা চ্যালেঞ্জ তৈরি করতে পারে। এন্ডপয়েন্ট সুরক্ষিত, ডেটা যাচাই করা এবং সম্ভবত এনক্রিপ্ট করা নিশ্চিত করা খুবই গুরুত্বপূর্ণ।

ব্যবহারের ক্ষেত্রে

• কন্টিনিউয়াস ইন্টিগ্রেশন অ্যান্ড ডিপ্লয়মেন্ট (সিআই/সিডি) : কোড পুশ করা হলে বা পুল রিকোয়েস্ট একত্রিত হলে বিল্ড এবং ডিপ্লয়মেন্ট ট্রিগার করে।

• কন্টেন্ট ম্যানেজমেন্ট সিস্টেম (CMS) : বিষয়বস্তু আপডেট, প্রকাশ বা মুছে ফেলা হলে ডাউনস্ট্রিম সিস্টেমগুলিকে অবহিত করা।

• পেমেন্ট গেটওয়েস : ই-কমার্স প্ল্যাটফর্মকে লেনদেনের ফলাফল সম্পর্কে অবহিত করা, যেমন সফল অর্থপ্রদান, ব্যর্থ লেনদেন বা ফেরত।

• সোশ্যাল মিডিয়া ইন্টিগ্রেশনস : সোশ্যাল মিডিয়া প্ল্যাটফর্মগুলিতে নতুন পোস্ট, উল্লেখ বা অন্যান্য প্রাসঙ্গিক ইভেন্ট সম্পর্কে বিজ্ঞপ্তি পাওয়া।

• IoT (ইন্টারনেট অফ থিংস) : ডিভাইস বা সেন্সরগুলি নির্দিষ্ট ইভেন্ট বা ডেটা রিডিং সম্পর্কে অন্যান্য সিস্টেম বা পরিষেবাগুলিকে অবহিত করতে ওয়েবহুকগুলিকে ট্রিগার করতে পারে৷

উদাহরণ

অনুরোধ

" https://external-site/webhooks?url=http://site/service-h/api&name=name " পান

প্রতিক্রিয়া

 { "webhook_id": 12 }

আরপিসি এবং জিআরপিসি

RPC (রিমোট প্রসিডিউর কল) হল একটি প্রোটোকল যা একটি প্রোগ্রামকে অন্য ঠিকানার জায়গায় একটি পদ্ধতি বা সাবরুটিন চালানোর অনুমতি দেয়, বিতরণ করা সিস্টেমের মধ্যে বিরামহীন যোগাযোগ এবং ডেটা বিনিময় সক্ষম করে।

gRPC (Google RPC) হল একটি আধুনিক, ওপেন-সোর্স ফ্রেমওয়ার্ক যা RPC-এর উপরে তৈরি করা হয় যা ট্রান্সপোর্টের জন্য HTTP/2 ব্যবহার করে এবং ইন্টারফেস বর্ণনার ভাষা হিসাবে প্রোটোকল বাফার ব্যবহার করে, যা প্রমাণীকরণ, লোড ব্যালেন্সিং এবং আরও অনেক কিছুর মতো বৈশিষ্ট্যগুলি প্রদান করে যাতে দক্ষ এবং শক্তিশালী যোগাযোগ সহজতর হয়। মাইক্রো সার্ভিসের মধ্যে।

আরপিসি

বিন্যাস : JSON, XML, Protobuf, Thrift, FlatBuffers

পরিবহন প্রোটোকল : বিভিন্ন

মূল ধারণা এবং বৈশিষ্ট্য

• সংজ্ঞা : RPC একটি প্রোগ্রামকে একটি পদ্ধতি (সাবরুটিন) অন্য ঠিকানার স্থানে (সাধারণত শেয়ার্ড নেটওয়ার্কে অন্য কম্পিউটারে) চালানোর অনুমতি দেয়। এটি কলারের চেয়ে আলাদা মেশিনে সম্পাদিত একটি ফাংশনকে কল করার মতো।

• স্টাবস : RPC-এর প্রেক্ষাপটে, স্টাবগুলি হল টুল দ্বারা তৈরি করা কোডের টুকরো যা স্থানীয় এবং দূরবর্তী পদ্ধতির কলগুলিকে একই রকম দেখাতে দেয়। ক্লায়েন্টের একটি স্টাব রয়েছে যা দূরবর্তী পদ্ধতির মতো দেখায়, এবং সার্ভারে একটি স্টাব রয়েছে যা আর্গুমেন্টগুলি আনপ্যাক করে, প্রকৃত পদ্ধতিতে কল করে এবং তারপরে ফেরত পাঠানোর জন্য ফলাফলগুলি প্যাক করে৷

• ডিফল্টরূপে সিঙ্ক্রোনাস : ঐতিহ্যগত RPC কলগুলি ব্লক করা হচ্ছে, যার অর্থ ক্লায়েন্ট সার্ভারে একটি অনুরোধ পাঠায় এবং সার্ভার থেকে প্রতিক্রিয়ার অপেক্ষায় ব্লক হয়ে যায়।

• ভাষা নিরপেক্ষ : অনেক RPC সিস্টেম বিভিন্ন ক্লায়েন্ট এবং সার্ভার বাস্তবায়নকে তারা যে ভাষায় লেখা হোক না কেন যোগাযোগ করার অনুমতি দেয়।

• টাইট কাপলিং : RPC প্রায়ই ক্লায়েন্ট এবং সার্ভারকে কল করা পদ্ধতি, এর পরামিতি এবং এর রিটার্ন টাইপ জানতে হয়।

ব্যবহারের ক্ষেত্রে

• ডিস্ট্রিবিউটেড সিস্টেম : RPC সাধারণত ডিস্ট্রিবিউটেড সিস্টেমে ব্যবহার করা হয় যেখানে সিস্টেমের কিছু অংশ বিভিন্ন মেশিন বা নেটওয়ার্কে ছড়িয়ে থাকে কিন্তু যোগাযোগ করতে হয় যেন সেগুলি স্থানীয়।

• নেটওয়ার্ক ফাইল সিস্টেম : NFS (নেটওয়ার্ক ফাইল সিস্টেম) হল RPC-র একটি উদাহরণ যা দূরবর্তীভাবে ফাইল অপারেশন করে।

উদাহরণ

অনুরোধ

 { "method": "addUser", "params": [ "Alex" ] }

প্রতিক্রিয়া

 { "id": 42, "name": "Alex", "error": null }

gRPC

বিন্যাস : প্রোটোবাফ

পরিবহন প্রোটোকল : HTTP/2

মূল ধারণা এবং বৈশিষ্ট্য

• সংজ্ঞা : gRPC হল একটি ওপেন সোর্স RPC ফ্রেমওয়ার্ক যা Google দ্বারা তৈরি করা হয়েছে। এটি পরিবহনের জন্য HTTP/2 ব্যবহার করে, ইন্টারফেস বর্ণনার ভাষা হিসাবে প্রোটোকল বাফার (প্রোটোবাফ) ব্যবহার করে এবং প্রমাণীকরণ, লোড ব্যালেন্সিং বৈশিষ্ট্য এবং আরও অনেক কিছু প্রদান করে।

• প্রোটোকল বাফার : এটি একটি ভাষা-নিরপেক্ষ, প্ল্যাটফর্ম-নিরপেক্ষ, স্ট্রাকচার্ড ডেটা সিরিয়ালাইজ করার জন্য এক্সটেনসিবল মেকানিজম। gRPC এর সাথে, আপনি প্রোটোবুফ ব্যবহার করে পরিষেবার পদ্ধতি এবং বার্তার ধরনগুলি সংজ্ঞায়িত করেন।

• কর্মক্ষমতা : gRPC কম লেটেন্সি এবং উচ্চ থ্রুপুট যোগাযোগের জন্য ডিজাইন করা হয়েছে। HTTP/2 একক সংযোগে একাধিক কল মাল্টিপ্লেক্স করার অনুমতি দেয় এবং ওভারহেড হ্রাস করে।

• স্ট্রিমিং : জিআরপিসি স্ট্রিমিং অনুরোধ এবং প্রতিক্রিয়া সমর্থন করে, দীর্ঘস্থায়ী সংযোগ, রিয়েল-টাইম আপডেট ইত্যাদির মতো আরও জটিল ব্যবহারের ক্ষেত্রে অনুমতি দেয়।

• সময়সীমা/সময়সীমা : gRPC ক্লায়েন্টদের নির্দিষ্ট করতে দেয় যে তারা একটি RPC সম্পূর্ণ হওয়ার জন্য কতক্ষণ অপেক্ষা করবে। সার্ভার এটি পরীক্ষা করতে পারে এবং সিদ্ধান্ত নিতে পারে যে ক্রিয়াকলাপটি সম্পূর্ণ করতে হবে বা যদি এটি খুব বেশি সময় নেয় তবে এটি বাতিল করা হবে।

• প্লাগেবল : gRPC প্লাগেবল প্রমাণীকরণ, লোড ব্যালেন্সিং, পুনরায় চেষ্টা ইত্যাদি সমর্থন করার জন্য ডিজাইন করা হয়েছে।

• ভাষা নিরপেক্ষ : RPC এর মত, gRPC হল ভাষা অজ্ঞেয়বাদী। যাইহোক, প্রোটোবুফ এবং জিআরপিসি টুলিংয়ের সাথে, একাধিক ভাষায় ক্লায়েন্ট এবং সার্ভার কোড তৈরি করা সহজ।

ব্যবহারের ক্ষেত্রে

• মাইক্রোসার্ভিসেস : জিআরপিসি সাধারণত মাইক্রোসার্ভিসেস আর্কিটেকচারে ব্যবহৃত হয় এর কার্যকারিতা বৈশিষ্ট্য এবং সহজে পরিষেবা চুক্তি সংজ্ঞায়িত করার ক্ষমতার কারণে।

• রিয়েল-টাইম অ্যাপ্লিকেশন : স্ট্রিমিংয়ের জন্য এটির সমর্থন দেওয়া হলে, জিআরপিসি রিয়েল-টাইম অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত যেখানে সার্ভারগুলি রিয়েল-টাইমে ক্লায়েন্টদের কাছে ডেটা পুশ করে।

• মোবাইল ক্লায়েন্ট : gRPC-এর কর্মক্ষমতা সুবিধা এবং স্ট্রিমিং ক্ষমতা এটিকে মোবাইল ক্লায়েন্টদের ব্যাকএন্ড পরিষেবার সাথে যোগাযোগের জন্য উপযুক্ত করে তোলে।

উদাহরণ

 message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); }

সাবান

SOAP , যা সিম্পল অবজেক্ট অ্যাক্সেস প্রোটোকলের জন্য দাঁড়িয়েছে, কম্পিউটার নেটওয়ার্কগুলিতে ওয়েব পরিষেবাগুলি বাস্তবায়নের জন্য কাঠামোগত তথ্য বিনিময়ের জন্য একটি প্রোটোকল। এটি একটি XML-ভিত্তিক প্রোটোকল যা ভিন্ন অপারেটিং সিস্টেমে চলমান প্রোগ্রামগুলিকে একে অপরের সাথে যোগাযোগ করতে দেয়।

বিন্যাস : XML

পরিবহন প্রোটোকল : HTTP/HTTPS, JMS, SMTP, এবং আরও অনেক কিছু

মূল ধারণা এবং বৈশিষ্ট্য

• XML-ভিত্তিক : SOAP বার্তাগুলি XML-এ ফর্ম্যাট করা হয় এবং এতে নিম্নলিখিত উপাদানগুলি থাকে:

  • খাম : একটি SOAP বার্তার মূল উপাদান যা XML নথিকে একটি SOAP বার্তা হিসাবে সংজ্ঞায়িত করে।

  
  

  • শিরোনাম : বার্তা প্রক্রিয়াকরণে ব্যবহৃত বার্তার কোনো ঐচ্ছিক বৈশিষ্ট্য রয়েছে, হয় একটি মধ্যস্থতাকারী বিন্দুতে বা চূড়ান্ত শেষ বিন্দুতে।

  
  

  • মূল অংশ : পাঠানো বার্তা সহ XML ডেটা রয়েছে৷

  
  

  • ফল্ট : একটি ঐচ্ছিক ফল্ট উপাদান যা বার্তা প্রক্রিয়া করার সময় ত্রুটি সম্পর্কে তথ্য প্রদান করে।

    
    

• নিরপেক্ষতা : SOAP যেকোন প্রোগ্রামিং মডেলের সাথে ব্যবহার করা যেতে পারে এবং একটি নির্দিষ্ট মডেলের সাথে আবদ্ধ নয়।

• স্বাধীনতা : এটি যেকোনো অপারেটিং সিস্টেমে এবং যেকোনো ভাষায় চলতে পারে।

• স্টেটলেস : ক্লায়েন্ট থেকে সার্ভারের প্রতিটি অনুরোধে অনুরোধটি বুঝতে এবং প্রক্রিয়া করার জন্য প্রয়োজনীয় সমস্ত তথ্য থাকতে হবে।

• অন্তর্নির্মিত ত্রুটি হ্যান্ডলিং : একটি SOAP বার্তার ত্রুটির উপাদানটি ত্রুটি প্রতিবেদনের জন্য ব্যবহৃত হয়।

• স্ট্যান্ডার্ডাইজড : SOAP স্পেসিফিকেশনের পাশাপাশি WS-ReliableMessaging এর মতো বার্তা সরবরাহ নিশ্চিত করার জন্য WS-Security, এবং আরও অনেক কিছু সহ সু-সংজ্ঞায়িত মানগুলির উপর ভিত্তি করে কাজ করে।

ব্যবহারের ক্ষেত্রে

• এন্টারপ্রাইজ অ্যাপ্লিকেশন : SOAP প্রায়শই এন্টারপ্রাইজ সেটিংসে ব্যবহৃত হয় এর দৃঢ়তা, প্রসারণযোগ্যতা এবং ফায়ারওয়াল এবং প্রক্সিগুলি অতিক্রম করার ক্ষমতার কারণে।

• ওয়েব পরিষেবা : অনেক ওয়েব পরিষেবা, বিশেষ করে পুরানোগুলি, SOAP ব্যবহার করে৷ এর মধ্যে Microsoft এবং IBM-এর মতো বড় কোম্পানির অফার করা পরিষেবা অন্তর্ভুক্ত রয়েছে।

• আর্থিক লেনদেন : SOAP-এর অন্তর্নির্মিত নিরাপত্তা এবং সম্প্রসারণযোগ্যতা এটিকে আর্থিক লেনদেনের জন্য একটি ভাল পছন্দ করে তোলে, যেখানে ডেটা অখণ্ডতা এবং নিরাপত্তা সবচেয়ে গুরুত্বপূর্ণ।

• টেলিকমিউনিকেশন : টেলিকম কোম্পানিগুলি বিলিং-এর মতো প্রক্রিয়াগুলির জন্য SOAP ব্যবহার করতে পারে, যেখানে বিভিন্ন সিস্টেমকে নির্ভরযোগ্যভাবে যোগাযোগ করতে হবে।

উদাহরণ

অনুরোধ

 <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserRequest> <m:Name>Alex</m:Name> </m:AddUserRequest> </soap:Body> </soap:Envelope>

প্রতিক্রিয়া

 <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserResponse> <m:Id>42</m:Id> <m:Name>Alex</m:Name> </m:AddUserResponse> </soap:Body> </soap:Envelope>

উপসংহার

API আর্কিটেকচার শৈলীর ল্যান্ডস্কেপ বৈচিত্র্যময়, যা REST, SOAP, RPC এবং আরও অনেক কিছুর মত বিভিন্ন পদ্ধতির অফার করে, প্রতিটি অনন্য শক্তি এবং ব্যবহারের ক্ষেত্রে, বিকাশকারীদেরকে বিভিন্ন সফ্টওয়্যারের মধ্যে মাপযোগ্য, দক্ষ এবং শক্তিশালী একীকরণ তৈরির জন্য সবচেয়ে উপযুক্ত দৃষ্টান্ত বেছে নিতে সক্ষম করে। উপাদান এবং সিস্টেম।