REST API: resource, validation ও error response
REST: Resources, Validation, and Errors
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Resource-oriented route ও HTTP semantics
- Form Request, authorization ও safe output
- Validation error এবং business conflict
সমস্যা দিয়ে শুরু
একটি API-তে সব route POST /do-action, আর body-তে action string। Client বুঝতে পারে না কোন request retry করা নিরাপদ, কোথায় resource ID পাওয়া যাবে বা validation fail হলে কী parse করবে। REST design-এর লক্ষ্য URL সুন্দর করা নয়; resource ও operation-এর স্থিতিশীল contract তৈরি করা।
সহজ করে বুঝি
Resource হলো API-তে চিহ্নিত concept, যেমন order বা product। GET representation পড়ে, POST collection-এ creation বা non-idempotent operation করতে পারে, PUT target representation replacement-এর semantics, PATCH partial modification। DELETE-এর repeated effect idempotent হতে পারে, response code এক হওয়া বাধ্যতামূলক নয়। Safe method read-oriented; safe ও idempotent একই শব্দ নয়। Validation shape/range যাচাই করে; authorization actor-এর permission দেখে। Stock-এর concurrent correctness transaction-এর আলাদা বিষয়।
পরিচিত একটি উপমা
লাইব্রেরির catalog-এ প্রতিটি বইয়ের পরিচয় আছে। বই দেখা, ধার নেওয়া এবং ফেরত দেওয়ার procedure আলাদা। Counter form পূরণ ঠিক হলেও সদস্যের অনুমতি ও বই আসলে available কি না আবার যাচাই করতে হয়। API validation-ও এমনই একটি ধাপ।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD C[API Client] --> A[Authenticate] A --> V[Form Request validation and policy] V --> B[Business action and transaction] B --> R[Explicit resource response] V --> E[Consistent validation error]
Authentication identity তৈরি করে। Form Request input contract ও authorization check করে। Business action invariant রক্ষা করে এবং resource serializer controlled output ফেরায়। Validation fail response আর database outage response আলাদা class; সব exception 200 response-এ লুকিয়ে ফেললে client retry ও monitoring ভুল হয়।
PHP ও Laravel-এ প্রয়োগ
App/Http/Requests/StoreOrderRequest.php-এর method fragment। routes/api.php route-এ auth:sanctum বা প্রকল্পের configured guard এবং controller-এ এই request inject করতে হবে। product permission policy আলাদা লাগতে পারে। এটি stock reservation বা payment code নয়।
public function authorize(): bool
{
return $this->user() !== null;
}
public function rules(): array
{
return [
'product_id' => ['required', 'integer', 'exists:products,id'],
'quantity' => ['required', 'integer', 'min:1', 'max:10'],
'note' => ['nullable', 'string', 'max:500'],
];
}সুবিধা, সীমাবদ্ধতা ও trade-off
Resource consistency client সহজ করে; কিন্তু সব operation CRUD-এ সুন্দর মেলে না। Order cancel-এর মতো explicit domain action উপযুক্ত endpoint হতে পারে। Standard status codes ব্যবহার করলেও application error code ও human message আলাদা রাখুন। 422 input validation, 401 missing/invalid authentication, 403 denied authorization এবং 409 domain conflict-এর ব্যবহার contract-এ নির্দিষ্ট করুন; framework convention ও client expectation মিলিয়ে নিন।
সাধারণ ভুল
- request->all() দিয়ে sensitive model field mass assign করা।
- GET request-এ order তৈরি বা payment charge করা।
- exists validation-কে concurrent stock guarantee মনে করা।
আরও একটু গভীরে
POST retry-এর জন্য scoped idempotency key contract দরকার হতে পারে। Key শুধু accept করলে হয় না: payload fingerprint, unique constraint, in-progress/result state এবং retention policy design করুন। Error response-এ stack trace, SQL বা secrets দেবেন না। Correlation ID troubleshooting সাহায্য করতে পারে, তবে user-visible message-এ internal exception verbatim পাঠাবেন না। Breaking field rename API version policy ছাড়া করবেন না।
মনে রাখুন
Resource identity, HTTP semantics এবং structured errors একই contract-এর অংশ। Validation, authorization ও business invariant আলাদা layers। Explicit output data leak কমায়।
নিজে চেষ্টা করুন
POST /orders, GET /orders/{id} এবং cancellation operation-এর contract লিখুন। Missing token, invalid quantity, অন্য user-এর order এবং sold-out product-এর expected status ও error body দিন। একই create request retry হলে কী হবে ব্যাখ্যা করুন।
নিজের বোঝা যাচাই করুন
1. REST মানেই CRUD?
না। Resource-oriented semantics useful baseline; domain operation-ও থাকতে পারে। Route naming-এর চেয়ে stable contract ও method behavior গুরুত্বপূর্ণ।
2. Idempotent মানে same response?
না। Repeated request-এর intended effect একই থাকে। প্রথম DELETE success আর পরে not found response হতে পারে।
3. Form Request stock রক্ষা করে?
না। Request validation-এর পরে stock বদলাতে পারে। Transaction, lock বা conditional update দিয়ে concurrency সামলাতে হবে।
4. 401 আর 403 কেন আলাদা?
Authentication establish হয়নি আর authenticated actor-এর permission নেই—দুটি আলাদা পরিস্থিতি। Client recovery behavior সেই অনুযায়ী বদলায়।
5. Model সরাসরি serialize করব?
Careful explicit resource ভালো। Hidden field ভুল configuration হলে private data বেরিয়ে যেতে পারে; output contract সচেতনভাবে নির্ধারণ করুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।