system-design-bangla

Principle of REST API

Client এবং Server পৃথক

REST Architecture এর প্রধান Principle হল Client এবং Server পৃথক থাকতে হবে। Client শুধু Request করবে এবং Server Response দিবে। User Interface এবং Data Storage পৃথক থাকবে।

Stateless

প্রতিটি Request self-contained হবে। Server কোনো Client Session Memory ধরে রাখবে না। Authentication, Authorization বা প্রয়োজনীয় Context প্রতিটি Request-এর সাথেই পাঠাতে হবে।

Uniform Interface

REST API এর সবচেয়ে গুরুত্বপূর্ণ Principle হল Uniform Interface। এর মানে হল, Client এবং Server এর মধ্যে communication এর জন্য একটি standard এবং consistent পদ্ধতি থাকতে হবে। Uniform Interface এর কয়েকটি মূল বিষয় হলঃ

• Resource Identification: প্রতিটি Resource কে একটি Unique URI দ্বারা চিহ্নিত করতে হবে। যেমন, /users/{id}, /products/{id}।
• Manipulation through Representations: Client যখন কোনো Resource এর Representation (যেমন JSON) পায়, তখন সেই Representation এর মাধ্যমেই Client সেই Resource কে modify বা delete করতে পারবে।
• Self-descriptive Messages: প্রতিটি Request এবং Response এ যথেষ্ট তথ্য থাকতে হবে, যাতে Client বা Server অন্য কোনো অতিরিক্ত তথ্য ছাড়াই সেই Message কে process করতে পারে। যেমন, HTTP Headers এ Content-Type উল্লেখ করা থাকে, যা বলে দেয় Body টি কোন format এ আছে (JSON/XML)।

Cacheable

Stateless হওয়ার পরেও আমরা Request এবং Response কে Cache করতে পারব।

REST Api মূলত ৫’টি প্রধান HTTP Methods দ্বারা স্টেট ট্রান্সফার নিশ্চিত করে থাকে।

GET

GET ম্যাথোড ব্যবহারের মাধ্যমে ক্লায়েন্ট কিছু স্পেসিফিক রির্সোস এর জন্য সার্ভারকে রিকুয়েস্ট করতে পারবে।

যেমন, ক্লায়েন্ট ইউজারদের লিস্ট এর জন্য রিকুয়েস্ট করতে পারে,

POST

POST Method মূলত Server-কে কোনো Request process করার জন্য ব্যবহৃত হয়। সবচেয়ে সাধারণ ব্যবহার হলো নতুন Resource তৈরি করা।

যেমন, ক্লায়েন্ট নতুন ইউজার তৈরি করতে সার্ভারকে POST রিকুয়েস্টের মাধ্যমে রিকুয়েস্ট করতে পারে,

PUT

PUT Method সাধারণত নির্দিষ্ট Resource সম্পূর্ণ replace বা update করার জন্য ব্যবহৃত হয়।

যেমন, ক্লায়েন্ট সার্ভারকে রিকুয়েস্ট করতে পারে কোন ইউজারের নাম পরিবর্তন করতে,

PATCH

PATCH ম্যাথোড ব্যবহার করা হয় কোন স্পেসিফিক রিসোর্সের স্পেসিফিক ভ্যালু পরিবর্তন করতে।

যেমন, ক্লায়েন্ট সার্ভারকে রিকুয়েস্ট করতে পারে কোন ইউজারের শুধু ইমেইল পরিবর্তন করতে,

DELETE

DELETE ম্যাথোড ব্যবহার করা হয় কোন স্পেসিফিক রিসোর্স ডিলিট করতে।

যেমন, ক্লায়েন্ট সার্ভারকে রিকুয়েস্ট করতে পারে কোন স্পেসিফিক ইউজার ডিলিট করতে যার নাম হবে John,

POST এবং PUT এর মধ্যে পার্থক্য

POST এবং PUT এর মধ্যে পার্থক্য হল, POST Method মূলত Server-কে কোনো Request process করার জন্য ব্যবহার করা হয়। সবচেয়ে সাধারণ ব্যবহার হলো নতুন Resource তৈরি করা, তবে POST শুধু Resource তৈরির মধ্যেই সীমাবদ্ধ নয়। Server-side processing প্রয়োজন এমন কাজেও POST ব্যবহার করা হয়। PUT হল idempotent মানে রিসোর্স যদি ইতিমধ্যে থাকে তাহলে সে আর নতুন রিসোর্স তৈরি করবে না।

PUT এবং PATCH এর মধ্যে পার্থক্য

PUT এবং PATCH এর মধ্যে পার্থক্য হল, PUT এর ক্ষেত্রে ক্লায়েন্ট একটি স্পেসিফিক ডাটার কিছু পরিবর্তন করতে চাইলে তাকে সেই ডাটার সম্পূর্ণ Attributes সার্ভারকে দিতে হবে এবং PATCH এর ক্ষেত্রে ক্লায়েন্ট সেই ডাটার যে Attribute পরিবর্তন হবে সেই Attribute টাই শুধু সার্ভারকে দিতে হবে।

অনেকে মনে করে থাকেন REST API মানে হচ্ছে GET/POST/PUT/DELETE। যা একটি ভুল ধারণা। এটি মূলত resource modeling + stateless design + uniform interface।

HTTP Headers

REST API তে Client এবং Server একে অপরের মধ্যে কিছু অতিরিক্ত তথ্য আদান-প্রধান করতে পারে তা করা হয় HTTP Headers ব্যবহার করে।

HTTP Headers কে ৪ category তে ভাগ করা হয়,

• Request headers: Client থেকে Server
• Response headers: Server থেকে Client
• Representation headers: Information about the body of the resource.
• Payload headers: Information about the payload data.

REST API best practices

• JSON format ব্যবহার করা রিকুয়েস্ট এবং রেসপন্সের পাঠানোর সময়। উদাহরণ,

router.get("/users", (req, res) => {
  res.status(200).json(users); // response format is JSON
});

• Noun ব্যবহার করা, verb এর পরিবর্তে। উদাহরণ,

--- recommended ---
'/users'
'/users/{id}'
'/products'

--- not recommended ---
'/get-users'
'/get-user'
'/fetch-products'

• Filtering, Sorting এর জন্য Query Params ব্যবহার করা। উদাহরণ,

{api_endpoint}/posts?tags=react

? এর পরের অংশটুকু হল Query Parameters.

• Health check endpoint তৈরী করে রাখা। উদাহরণ, /health - যা বলে দিবে সার্ভিস healthy আছে কি না।

• ISO 8601 UTC dates ব্যবহার করা। যখন আমরা Time এবং Date নিয়ে কাজ করবো তখন ISO 8601 UTC dates আকারে সার্ভার থেকে ক্লায়েন্টের কাছে পাঠিয়ে দিবো। নির্দিষ্ট time-zone এ দেখানো তা ক্লায়েন্ট সাইড এর বিষয়।

• নির্দিষ্ট রেস্পন্সের জন্য নির্দিষ্ট Status Code ব্যবহার করা।

Rest API security best practices

• HTTPS ব্যবহার করা।
• properly Authorization implement করা।
• Rate Limiter ব্যবহার করা।
• User এর দেয়া Input, Validate করা।
• OWASP API Security Risks নিয়ে সাবধান থাকা।

Rest API performance best practices

Caching

Caching নিয়ে আমার লিখা পড়তে পারেন

CDN

Caching নিয়ে আমার লিখা পড়তে পারেন

Pagination

২ রকমের pagination techniques আমাদের কাছে আছে। Offset এবং Cursor। আমাদের requirements এর উপর ভিত্তি করে আমরা pagination technique ব্যবহার করব।

Data Compression

Data Compressed করলে আমরা API response এর size কমাতে পারবো।

Unnecessary property send to payload and response

Payload এবং Response এর মধ্যে অপ্রয়োজনীয় প্রপার্টি(object, array) পাঠাবো না।

HTTP Status Code

HTTP Status Code আমাদেরকে বলে দেয় একটি নির্দিষ্ট HTTP Method(GET, POST, PUT) এর রিকুয়েস্ট সাকসেসফুল হয়েছে কি না।

এটি ব্যবহার করা একটি উওম প্রাকটিস বলে গণ্য করা হয়।

HTTP Status Code কে পাঁচ শ্রেণিতে ভাগ করা হয়,

• Informational Responses(100-199)
• Successful Responses(200-299)
• Redirects(300-399)
• Client Errors(400-499)
• Server Errors(500-599)

নিচে কিছু HTTP Status Code এর নির্দিষ্ট ব্যবহার বলা হল,

• 200, মানে হল রিকুয়েস্ট সাকসেস হয়েছে।
• 201, মানে হল রিকুয়েস্ট সাকসেস হয়েছে এবং নতুন রিসোর্স তৈরি হয়েছে। (উদাহরণঃ নতুন ইউজার রেজিস্ট্রেশন)
• 400, মানে হল সার্ভার বুজতে পারছে না client দ্বারা কোন ভুল সিনট্যাক্স বা ভুল তথ্য দেয়ার জন্য।
• 401, হল unauthorized, মানে ক্লায়েন্ট এমন কিছুর জন্য রিকুয়েস্ট করেছে যার জন্য সে authorized না।
• 404, মানে হল সার্ভার রেসপন্সটি খুঁজে পায় নাই।
• 409, মানে request এর মধ্যে কোনো প্রকারের conflict আছে।
• 500, মানে সার্ভার এমন কিছু Error পেয়েছে যা সে জানে না কিভাবে ঠিক করবে।

আরও জানতে এই লিংকে যেতে পারেন, https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

REST API এবং GraphQL এর মধ্যে পার্থক্য

• Data Fetching

  • REST API তে সার্ভার ডিফাইন করে দেয় রেস্পন্সের গঠন।
  • GraphQL এ ক্লায়েন্ট রিকোয়েস্ট এর সাথে বলে দেয় কোন কোন ডেটা ক্লায়েন্ট এর প্রয়োজন, সার্ভার সেই ডেটাগুলো ক্লায়েন্টকে দিয়ে থাকে।

• Over Fetching of data

  • REST API তে যেহেতু সার্ভার রেস্পন্সের গঠন ডিফাইন করে দেয় সেজন্য data overfetching হওয়ার সম্ভাবনা থাকে।
  • GraphQL এ যেহেতু ক্লায়েন্ট রিকোয়েস্ট এর সাথে বলে দেয় কোন কোন ডেটা ক্লায়েন্ট এর প্রয়োজন, সেজন্য data overfetching হওয়ার সম্ভাবনা থাকে না।

• Error Handling

  • REST API সাধারণত Weakly Typed বা স্কিমা বিহীন হয়। রিকোয়েস্ট-রেসপন্সের টাইপ রানটাইমে ভ্যালিডেশন করতে হয়।
  • GraphQL হল Strongly Typed মানে ডেটার স্ট্রাকচার এবং যেসব ডেটা রিকোয়েস্ট করা হচ্ছে সেগুলোর টাইপ well-defined এবং validated থাকতে হবে।

Idempotent API

Idempotent API বলতে বোঝায় - একটি নির্দিষ্ট API রিকোয়েস্ট একবার কল করলে সার্ভারে যে পরিবর্তন বা স্টেট ট্রান্সফার হয়, একই প্যারামিটার দিয়ে সেই রিকোয়েস্টটি বারবার (১০০ বারও) কল করলেও সার্ভারের স্টেটে ঠিক একই প্রভাব থাকবে, নতুন কোনো পরিবর্তন হবে না। অর্থাৎ, একাধিকবার একই রিকোয়েস্ট পাঠালেও চূড়ান্ত ফলাফল সবসময় একই থাকবে।

GET, PUT, DELETE, HEAD এবং OPTIONS idempotent। POST সাধারণত non-idempotent। PATCH idempotent হবে কি না, তা API-এর implementation-এর উপর নির্ভর করে।

আপনি যখন GET api ব্যবহার করে বার বার কিংবা api retry করে api call করবেন তখন আপনি নির্দিষ্ট রিসোর্স পাবেন, ডেটাবেসে কোনো নতুন রিসোর্স তৈরী হবে না। একই ভাবে PUT এবং DELETE এর ক্ষেত্রেও সমান, ঐখানে নতুন রিসোর্স তৈরী হবে না বরং নির্দিষ্ট রিসোর্স আপডেট এবং ডিলিট হবে। POST সাধারণত নতুন Resource তৈরি বা Server-side processing-এর জন্য ব্যবহৃত হয়। অন্যদিকে PATCH বিদ্যমান Resource-এর আংশিক (partial) পরিবর্তনের জন্য ব্যবহৃত হয়।

কেন এবং কিভাবে API কে Idempotent বানানো যায়?

ধরুন আপনি কোনো কিছুর জন্য Payment করছেন, আপনি Payment button click করার পর আপনার রিকোয়েস্ট সার্ভারে প্রসেস হচ্ছে এখন প্রসেস হওয়ার সময় আপনি কোনোভাবে আবার Payment button click করলেন। এখন সার্ভারের কাছে আপনার দুটি রিকোয়েস্ট আছে, সার্ভার আপনার দুটি payment request প্রসেস করবে। এতে করে আপনার payment একবার এর জায়গায় দুবার (payment) হয়ে গেলো।

এরকম আরো অনেক scenario আছে যেখানে API মানে POST API Idempotent না হওয়ার কারণে আপনার সিস্টেম এর End User এর ক্ষতি হতে পারে।

এই সমস্যার সমাধানের জন্য আমরা একটি পদ্ধতি মেনে চলতে পারি,

• স্টেপ ১: প্রতিটি API রিকোয়েস্ট এ আমরা একটি ইউনিক (UUID/ULID) ভ্যালু HEADER এর সাথে সংযোগ করে দিয়ে দিব।
• স্টেপ ২: প্রথমবার আমরা ডেটাবেসে কিংবা cache এর ভিতর ইউনিক ভ্যালু এর স্টেট processing হিসাবে রেখে দিব।

——– এতেই প্রথমবারের মত API request তার response পেয়ে যাবে ——-

• স্টেপ ৩: পরবর্তী সময়ে API retry এর ফলে যখন আরেকটি API রিকোয়েস্ট আসবে তখন সার্ভার এই(একই) ইউনিক (UUID) ভ্যালু ডেটাবেসে কিংবা cache এর ভিতর চেক করে দেখবে এই ভ্যালুর বর্তমান স্টেট কি।
• স্টেপ ৪: স্টেট যদি consumed কিংবা processing হয়ে থাকে আমরা API রিকোয়েস্ট কে রিটার্ন করে দিব, নতুনভাবে কোনো প্রকারের প্রসেস করা ছাড়া।

বি:দ্র: অনেকের মনে প্রশ্ন আসতে পারে ইউনিক key কোথায় তৈরী করবো? সাধারণত security দিক থেকে চিন্তা করলে ইউনিক key সার্ভার থেকে তৈরী হয়ে আসা ভালো। ক্লায়েন্ট থেকে key তৈরী করলে security concern থেকে যায়।

গুরুত্বপূর্ণ প্রশ্নগুলো

• কোন প্রকারের প্রোটোকল REST API ব্যবহার করে?
• REST API এর Principle গুলো কি কি?
• POST এবং PUT এর মধ্যে কি কি পার্থক্য?
• PUT এবং PATCH এর মধ্যে কি কি পার্থক্য?
• Idempotent API কি? কিভাবে API কে Idempotent বানানো যায়?
• REST API এর Best Practice গুলো কি কি?
• API এর Latency 100ms থেকে 2s বেড়ে গেলে আপনি কি করবেন?
• আপনার API তে ট্রাফিক এর পরিমাণ হঠাৎ করে 10x বৃদ্ধি পেলে, আপনি প্রথমে কি চেক করবেন?
• আপনি কিভাবে API কিভাবে ডিসাইন যাতে ভবিষ্যতে নতুন ফিচার যোগ বা পরিবর্তন করলেও পুরনো ক্লায়েন্টগুলো ভেঙে না যায় (break না করে)?

This site is open source. Improve this page.