REST API: এটি কী, HTTP পদ্ধতি এবং মোবাইল অ্যাপ্লিকেশনে কাজের নীতি

REST API কী?

REST API (Representational State Transfer API) একটি আর্কিটেকচারাল শৈলী যা রয় ফিল্ডিং ২০০০ সালে তার ডক্টরেট গবেষণাপত্রে প্রস্তাব করেছিলেন। এটি নেটওয়ার্ক প্রোটোকল ডিজাইনের জন্য বিধিনিষেধ এবং নীতির একটি সেট সংজ্ঞায়িত করে। এই বিধিনিষেধগুলি মেনে চলা API-কে RESTful বলা হয়। REST কোনো প্রোটোকল বা মানক নয় — এটি একটি আর্কিটেকচারাল পদ্ধতি যা ক্লায়েন্ট এবং সার্ভারের মধ্যে ডেটা বিনিময়ের জন্য বিদ্যমান প্রোটোকল (প্রধানত HTTP) ব্যবহার করে।

REST-এর মূল ধারণা হল সংস্থান-ভিত্তিক আর্কিটেকচার। সার্ভারে পদ্ধতি কল করার পরিবর্তে (যেমন SOAP বা RPC-তে), ক্লায়েন্ট সংস্থানগুলির উপর কাজ করে: তালিকা পায়, নতুন তৈরি করে, আপডেট বা মুছে ফেলে। প্রতিটি সংস্থান একটি ডোমেন সত্তা: ব্যবহারকারী, অর্ডার, পণ্য, নিবন্ধ। একটি সংস্থানের একটি অবস্থা থাকে যা ক্লায়েন্টকে মানকৃত ফর্ম্যাটে পাঠানো হয়, সাধারণত JSON। সার্ভার অনুরোধগুলির মধ্যে ক্লায়েন্টের অবস্থা সংরক্ষণ করে না — এটি stateless নীতি, REST-এর একটি মূল প্রয়োজনীয়তা।

REST API-এর প্রধান বৈশিষ্ট্য:

• Stateless — ক্লায়েন্টের প্রতিটি অনুরোধ প্রক্রিয়াকরণের জন্য প্রয়োজনীয় সমস্ত তথ্য ধারণ করে
• Cacheable — সার্ভারের প্রতিক্রিয়াগুলি স্পষ্টভাবে ক্যাশযোগ্য বা অ-ক্যাশযোগ্য হিসাবে চিহ্নিত করা উচিত
• Layered system — আর্কিটেকচারে মধ্যবর্তী সার্ভার, লোড ব্যালেন্সার, প্রক্সি অন্তর্ভুক্ত থাকতে পারে
• Uniform interface — HTTP পদ্ধতি, URL এবং অবস্থা কোডের মাধ্যমে একীভূত ইন্টারফেস

REST আর্কিটেকচারের নীতিমালা

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

Uniform Interface নীতিতে অতিরিক্তভাবে চারটি উপ-বিধিনিষেধ অন্তর্ভুক্ত রয়েছে: URI-এর মাধ্যমে সংস্থান সনাক্তকরণ, প্রতিনিধিত্বের মাধ্যমে সংস্থান পরিচালনা, স্ব-বর্ণনাকারী বার্তা এবং HATEOAS (অ্যাপ্লিকেশন অবস্থার ইঞ্জিন হিসাবে হাইপারমিডিয়া)। শেষ উপ-বিধিনিষেধটি প্রায়শই বাস্তবে উপেক্ষিত হয় — অধিকাংশ আধুনিক REST API সম্পূর্ণরূপে HATEOAS প্রয়োগ করে না, যা নিয়ে আলোচনা হয় যে এই ধরনের API “সত্যিই” RESTful কিনা।

Stateless নীতিটি স্কেলিংয়ের জন্য সবচেয়ে গুরুত্বপূর্ণ। সার্ভারে সেশনের অনুপস্থিতির অর্থ হল যে কোনও সার্ভার ইনস্ট্যান্স যে কোনও অনুরোধ প্রক্রিয়া করতে পারে। এটি অনুভূমিক স্কেলিংকে সরল করে: লোড ব্যালেন্সারের পিছনে নতুন সার্ভার যুক্ত করাই যথেষ্ট। মোবাইল অ্যাপ্লিকেশনের জন্য, stateless এর অর্থ হল যে একটি অনুরোধ যে কোনও CDN সার্ভারে পাঠানো যেতে পারে, যা বিশ্বব্যাপী প্রাপ্যতার জন্য গুরুত্বপূর্ণ।

REST-এ HTTP পদ্ধতি

REST API-তে প্রতিটি HTTP পদ্ধতি একটি সংস্থানের উপর একটি নির্দিষ্ট অপারেশনের সাথে মিলে যায়: পড়ার জন্য GET, তৈরির জন্য POST, সম্পূর্ণ আপডেটের জন্য PUT, আংশিক আপডেটের জন্য PATCH, মুছে ফেলার জন্য DELETE। পদ্ধতিগুলির আইডেম্পোটেন্সি একটি মূল বৈশিষ্ট্য: GET, PUT, DELETE আইডেম্পোটেন্ট (পুনরাবৃত্তি নির্বাহ একই ফলাফল দেয়), POST এবং PATCH নয়। এটি নেটওয়ার্ক ত্রুটিগুলি পরিচালনার জন্য গুরুত্বপূর্ণ যখন ক্লায়েন্ট জানে না যে অনুরোধটি সার্ভারে পৌঁছেছে কিনা।

• GET — একটি সংস্থান বা সংস্থানের তালিকা প্রাপ্তি। আইডেম্পোটেন্ট, সার্ভারের অবস্থা পরিবর্তন করে না
• POST — একটি নতুন সংস্থান তৈরি। আইডেম্পোটেন্ট নয়, প্রতিটি কল একটি নতুন সংস্থান তৈরি করে
• PUT — সংস্থানের সম্পূর্ণ প্রতিস্থাপন। আইডেম্পোটেন্ট, প্রথমটির পরে পুনরাবৃত্তি কল অবস্থা পরিবর্তন করে না
• PATCH — সংস্থানের আংশিক আপডেট। আংশিকভাবে আইডেম্পোটেন্ট (বাস্তবায়নের উপর নির্ভর করে)
• DELETE — সংস্থান মুছে ফেলা। আইডেম্পোটেন্ট, পুনরাবৃত্তি মুছে ফেলায় 404 ফেরত আসে, ত্রুটি নয়

HTTP অবস্থা কোডগুলি REST API-এর একটি অবিচ্ছেদ্য অংশ। প্রতিটি কোডের একটি নির্দিষ্ট অর্থ রয়েছে: সফল GET-এর জন্য 200 OK, POST-এর জন্য 201 Created, প্রতিক্রিয়া বডি ছাড়া DELETE-এর জন্য 204 No Content, অবৈধ ডেটার জন্য 400 Bad Request, প্রমাণীকরণের অভাবের জন্য 401 Unauthorized, সংস্থান না থাকলে 404 Not Found। অবস্থা কোডগুলির সঠিক ব্যবহার API-কে স্ব-ডকুমেন্টিং করে এবং ডিবাগিং সহজ করে।

ডেটা ফর্ম্যাট: JSON এবং অন্যান্য

JSON (JavaScript Object Notation) REST API-তে ডেটা স্থানান্তরের প্রধান ফর্ম্যাট। এর জনপ্রিয়তা সরলতা, মানব-পাঠযোগ্যতা এবং JavaScript-এ নেটিভ সমর্থনের কারণে। JSON Content-Type: application/json হেডার সহ প্রেরিত হয়। বিকল্পগুলির মধ্যে রয়েছে XML (জটিল, পুরাতন), YAML (কনফিগারেশনের জন্য সুবিধাজনক, API-র জন্য কম সাধারণ), এবং Protocol Buffers (বাইনারি, উচ্চ-লোড সিস্টেমের জন্য কার্যকর)।

REST API-তে JSON অবজেক্টের কাঠামোতে সাধারণত id, type ফিল্ড এবং সংস্থান বৈশিষ্ট্য অন্তর্ভুক্ত থাকে। সংগ্রহের জন্য, পেজিনেশন মেটাডেটা সহ JSON অ্যারে ব্যবহার করা হয়। আধুনিক REST API প্রতিক্রিয়া বৈধতার জন্য JSON:API স্পেসিফিকেশন (jsonapi.org) বা JSON Schema অনুসরণ করে। একীভূত ডেটা ফর্ম্যাট ব্যবহার ক্লায়েন্ট লাইব্রেরি ডেভেলপমেন্ট এবং ডকুমেন্টেশন জেনারেশন সহজ করে।

ব্যবহারকারীদের তালিকার জন্য JSON প্রতিক্রিয়ার উদাহরণ:

{
    "data": [
        {
            "id": 1,
            "name": "আনা পেট্রোভা",
            "email": "anna@example.com"
        }
    ],
    "meta": {
        "total": 42,
        "page": 1,
        "per_page": 10
    }
}

ডেটা স্থানান্তর ফর্ম্যাটের পছন্দ মোবাইল অ্যাপ্লিকেশনের কর্মক্ষমতা প্রভাবিত করে। JSON GZIP-এর মাধ্যমে 70-80% সংকুচিত হয়, যা এটিকে বেশিরভাগ পরিস্থিতির জন্য গ্রহণযোগ্য করে তোলে। বড় ডেটা ভলিউম (স্ট্রিমিং, গেমিং) সহ রিয়েল-টাইম অ্যাপ্লিকেশনের জন্য, বাইনারি প্রোটোকলে স্যুইচ করা বা Protocol Buffers-এর সাথে WebSocket ব্যবহার করার পরামর্শ দেওয়া হয়।

REST API অনুরোধের উদাহরণ

মোবাইল অ্যাপ্লিকেশনের পক্ষ থেকে REST API-এর সাথে কাজ করার ব্যবহারিক উদাহরণ দেখি। উদাহরণ হিসাবে, একটি অনলাইন স্টোরে অর্ডার নিয়ে কাজ করার জন্য একটি API নেওয়া যাক। প্রতিটি HTTP পদ্ধতির জন্য, একটি অনুরোধ এবং প্রত্যাশিত সার্ভার প্রতিক্রিয়া দেখানো হয়েছে। উদাহরণগুলি মোবাইল ডেভেলপমেন্টে ব্যবহৃত সাধারণ RESTful API কাঠামো প্রদর্শন করে।

GET — অর্ডারের তালিকা প্রাপ্তি

পেজিনেশন সহ সমস্ত ব্যবহারকারীর অর্ডার প্রাপ্তির অনুরোধ। প্রতিক্রিয়ায় অর্ডার অবজেক্টের একটি অ্যারে এবং পৃষ্ঠা নেভিগেশনের জন্য মেটা-তথ্য থাকে। page এবং per_page প্যারামিটারগুলি query string-এর মাধ্যমে পাঠানো হয়।

// REST API-র জন্য Retrofit ইন্টারফেস
interface OrderApi {
    @GET("api/v1/orders")
    suspend fun getOrders(
        @Query("page") page: Int = 1,
        @Query("per_page") perPage: Int = 20
    ): Response<OrderListResponse>
}

POST — নতুন অর্ডার তৈরি

POST অনুরোধের মাধ্যমে নতুন অর্ডার তৈরি। সার্ভার 201 Created অবস্থা এবং প্রতিক্রিয়া বডিতে তৈরি করা অবজেক্ট ফেরত দেয়। গুরুত্বপূর্ণ: তৈরি করা সংগ্রহ /api/v1/orders-এ করা হয়, নির্দিষ্ট কোনও সংস্থানে নয় — এটি মানক RESTful প্যাটার্ন।

@POST("api/v1/orders")
suspend fun createOrder(
    @Body order: CreateOrderRequest
): Response<OrderResponse>

// অনুরোধ বডির উদাহরণ
data class CreateOrderRequest(
    val productId: String,
    val quantity: Int,
    val addressId: String
)

DELETE — অর্ডার মুছে ফেলা

একটি সংস্থান মুছে ফেলা নির্দিষ্ট অর্ডার URL-এ DELETE পদ্ধতি দিয়ে করা হয়। সফল মুছে ফেলায় 204 No Content ফেরত আসে। DELETE-এর আইডেম্পোটেন্সির অর্থ হল একই URL-এ পুনরাবৃত্তি অনুরোধ 404 Not Found ফেরত দেয়, যা ক্লায়েন্টে সঠিকভাবে পরিচালিত হয়।

@DELETE("api/v1/orders/{id}")
suspend fun deleteOrder(
    @Path("id") orderId: String
): Response<Unit>

// ViewModel-এ ব্যবহার
fun removeOrder(orderId: String) {
    viewModelScope.launch {
        val response = api.deleteOrder(orderId)
        if (response.isSuccessful) {
            showSuccess()
        }
    }
}

এই উদাহরণগুলি Android পক্ষে Retrofit এবং Kotlin Coroutines ব্যবহার করে একটি সাধারণ REST API বাস্তবায়ন প্রদর্শন করে। iOS অ্যাপ্লিকেশনের জন্য, URLSession বা Alamofire লাইব্রেরি Codable প্রোটোকলের সাথে একই ভূমিকা পালন করে। REST API কাঠামো প্ল্যাটফর্ম নির্বিশেষে একই থাকে — শুধু অনুরোধ করার পদ্ধতি পরিবর্তিত হয়।

RESTful API ডিজাইন: ব্যবহারিক সুপারিশ

গুণগত RESTful API ডিজাইন করার জন্য ডেভেলপারদের জন্য API-কে স্বজ্ঞাত করে তোলে এমন নিয়মাবলী অনুসরণ করা প্রয়োজন। সংস্থানগুলিকে বহুবচন বিশেষ্য (/users, /orders, /products) দিয়ে নামকরণ করা উচিত, HTTP পদ্ধতিগুলিকে অপারেশন প্রতিফলিত করা উচিত এবং URL-গুলিকে নেস্টিং শ্রেণিবিন্যাস উপস্থাপন করা উচিত। ত্রুটিগুলি শুধু HTTP অবস্থা নয়, একটি কোড এবং বার্তা সহ মানকৃত JSON ফেরত দেওয়া উচিত। এই নিয়মাবলী মেনে চলা নতুন ডেভেলপারদের জন্য প্রবেশের বাধা কমায় এবং একীকরণ সহজ করে।

• সংস্থান নামকরণ — বহুবচন, kebab-case: /api/v1/user-orders, /api/v1/getUserOrders নয়
• ফিল্টারিং এবং সাজানো — query প্যারামিটারের মাধ্যমে: ?status=active&sort=created_at:desc
• পেজিনেশন — বড় সেটের জন্য কার্সর-ভিত্তিক, ছোটের জন্য পৃষ্ঠা-ভিত্তিক
• সংস্করণ নিয়ন্ত্রণ — URL (/api/v2/) বা Accept-Version হেডারের মাধ্যমে
• ত্রুটিসমূহ — একীভূত ফর্ম্যাট: { "error": { "code": "VALIDATION_ERROR", "message": "..." } }
• রেট লিমিটিং — X-RateLimit-Remaining এবং Retry-After হেডার

REST API ডিজাইন করার সময় একটি সাধারণ ভুল অত্যধিক সংস্থান নেস্টিং। /users/1/orders/5/items/3-এর পরিবর্তে, query প্যারামিটার সহ ফ্ল্যাট কাঠামো ব্যবহার করা ভাল: /items?order_id=5&user_id=1। এটি ক্যাশিং সহজ করে, সার্ভারে দীর্ঘ পাথ বজায় রাখার প্রয়োজন হয় না এবং ডকুমেন্টেশন করা সহজ। ফ্ল্যাট আর্কিটেকচার ভবিষ্যতে GraphQL-এ মাইগ্রেট করার সময় গ্রাফ-ভিত্তিক কোয়েরির সাথে আরও ভাল সামঞ্জস্যপূর্ণ।

REST API সুরক্ষা প্রমাণীকরণ (JWT, OAuth 2.0) এবং সংস্থান স্তরে অনুমোদন-এর মাধ্যমে বাস্তবায়িত হয়। প্রতিটি অনুরোধ পরীক্ষা করা উচিত যে ব্যবহারকারীর অনুরোধকৃত সংস্থানে অ্যাক্সেস আছে কিনা। HTTPS বাধ্যতামূলক — এনক্রিপশন ছাড়া, টোকেন এবং ডেটা প্লেইন টেক্সটে প্রেরিত হয়। মোবাইল অ্যাপ্লিকেশনের জন্য, সুরক্ষিত টোকেন প্রাপ্তির জন্য PKCE (Proof Key for Code Exchange) সহ OAuth 2.0 ব্যবহার করার পরামর্শ দেওয়া হয়।

সংস্করণ নিয়ন্ত্রণ এবং ক্যাশিং

REST API-র সংস্করণ নিয়ন্ত্রণ পরিবর্তনের সময় পিছনের দিকের সামঞ্জস্যের জন্য প্রয়োজনীয়। সবচেয়ে সাধারণ পদ্ধতিগুলি হল: URL-এ সংস্করণ (/api/v1/orders), হেডারে সংস্করণ (Accept: application/vnd.myapi.v1+json), এবং query প্যারামিটারে সংস্করণ (?api_version=1)। URL সংস্করণ সবচেয়ে জনপ্রিয় পদ্ধতি কারণ এটি লগ এবং ডকুমেন্টেশনে স্পষ্টভাবে দৃশ্যমান। তবে, এটি প্রতি সংস্থানে একক URL-এর REST নীতি লঙ্ঘন করে।

REST API-তে ক্যাশিং HTTP হেডার Cache-Control, ETag এবং Last-Modified-এর মাধ্যমে বাস্তবায়িত হয়। ক্যাশযোগ্য হিসাবে চিহ্নিত GET অনুরোধ সার্ভারের সাথে যোগাযোগ না করে ব্রাউজার বা প্রক্সি ক্যাশ থেকে পরিবেশিত হতে পারে। মোবাইল অ্যাপ্লিকেশনের জন্য, ক্যাশিং বিশেষভাবে গুরুত্বপূর্ণ — এটি ডেটা খরচ কমায় এবং দুর্বল সংযোগে পূর্বে লোড করা ডেটা প্রদর্শন দ্রুত করে। ETag প্রতিক্রিয়া বিষয়বস্তুর একটি হ্যাশ: ক্লায়েন্ট এটি If-None-Match-এ পাঠায় এবং ডেটা পরিবর্তন না হলে সার্ভার 304 Not Modified ফেরত দেয়।

REST API-র আধুনিক বিকল্পগুলির মধ্যে রয়েছে GraphQL (নমনীয় ক্লায়েন্ট-সাইড ডেটা ফেচিং) এবং gRPC (মাইক্রোসার্ভিসের জন্য HTTP/2-এর উপর বাইনারি প্রোটোকল)। তবে, REST তার সরলতা, সার্বজনীনতা এবং বিস্তৃত টুল সমর্থনের কারণে পাবলিক API-র জন্য প্রধান মানক হিসাবে রয়ে গেছে। REST এবং বিকল্পগুলির মধ্যে পছন্দ প্রকল্পের নির্দিষ্ট প্রয়োজনীয়তার উপর নির্ভর করে: কোয়েরি জটিলতা, ডেটা ভলিউম, রিয়েল-টাইম আপডেটের প্রয়োজনীয়তা।