CodeGym /Java Blog /এলোমেলো /REST এর ওভারভিউ। পার্ট 2: ক্লায়েন্ট এবং সার্ভারের মধ্যে ...
John Squirrels
লেভেল 41
San Francisco

REST এর ওভারভিউ। পার্ট 2: ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ

এলোমেলো দলে প্রকাশিত
REST এর ওভারভিউ। পর্ব 1: বিশ্রাম কি? এই অংশে, আমরা একটি ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ কিভাবে সঞ্চালিত হয় তার গভীরে ডুব দেব। পথে, আমরা নতুন শর্তাবলী উন্মোচন করব এবং তাদের ব্যাখ্যা করব। REST এর ওভারভিউ।  পার্ট 2: একটি ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ - 1সবকিছু পরিষ্কার নিশ্চিত করতে, আমরা উদাহরণ হিসেবে একটি RESTful অ্যাপ্লিকেশন ব্যবহার করে ক্লায়েন্ট-সার্ভার যোগাযোগ বিশ্লেষণ করব। ধরুন আমরা একটি ওয়েব অ্যাপ্লিকেশন তৈরি করছি যা গ্রাহকদের এবং তাদের অর্ডার সম্পর্কে তথ্য সংরক্ষণ করে। অন্য কথায়, আমাদের সিস্টেম কিছু নির্দিষ্ট সত্তার উপর ক্রিয়াকলাপ সম্পাদন করতে সক্ষম: সেগুলি তৈরি, সম্পাদনা এবং মুছে ফেলুন এবং তাদের সম্পর্কে তথ্য প্রদর্শন করুন৷ এই সংস্থাগুলি হবে:
  • গ্রাহক (গ্রাহক)
  • আদেশ (গ্রাহকের আদেশ)
  • আইটেম (পণ্য)
একটি RESTful আর্কিটেকচারে, ক্লায়েন্টরা ডেটা পুনরুদ্ধার বা সংশোধন করার জন্য একটি সার্ভারে অনুরোধ পাঠায় এবং তারপর সার্ভারগুলি ক্লায়েন্টদের তাদের অনুরোধের প্রতিক্রিয়া পাঠায়।

অনুরোধ

ক্লায়েন্ট অনুরোধ প্রায় সবসময় HTTP প্রোটোকল ব্যবহার করে করা হয়. সাধারণভাবে, HTTP অনুরোধগুলি বিভিন্ন উপাদান নিয়ে গঠিত:
  • HTTP পদ্ধতি
  • হেডার
  • ইউআরআই
  • অনুরোধ শরীরের
নীচে আমরা প্রতিটি উপাদানকে আরও বিশদে বিবেচনা করব।

URI এবং সম্পদ

ক্লায়েন্টরা অনুরোধের মাধ্যমে যে ডেটা গ্রহণ করে বা পরিবর্তন করে তাকে সম্পদ বলা হয়। ক্লায়েন্ট-সার্ভার কমিউনিকেশন হল রিসোর্স ম্যানিপুলেট করা। REST-এ, সম্পদ এমন কিছু যা আপনি একটি নাম দিতে পারেন। এক অর্থে, তারা জাভাতে ক্লাসের মতো। জাভাতে, আমরা যেকোনো কিছুর জন্য একটি ক্লাস তৈরি করতে পারি। সুতরাং REST-এ, একটি সংস্থান যেকোনো কিছু হতে পারে: একটি ব্যবহারকারী, একটি নথি, একটি প্রতিবেদন, একটি আদেশ৷ এটি হয় কিছু সত্তার একটি বিমূর্ততা, বা নির্দিষ্ট কিছু, উদাহরণস্বরূপ, একটি চিত্র, ভিডিও, অ্যানিমেশন বা PDF ফাইল হতে পারে৷ আমাদের উদাহরণে, আমাদের 3 টি সংস্থান রয়েছে:
  • গ্রাহক (গ্রাহক)
  • আদেশ (গ্রাহকের আদেশ)
  • আইটেম (পণ্য)
ক্লায়েন্টরা রিসোর্স লোকেশনে অনুরোধ পাঠায় যা এন্ডপয়েন্ট নামে পরিচিত। সহজ করে বললে, একটি এন্ডপয়েন্ট হল নেটওয়ার্কের একটি ঠিকানার মতো। গভীরে ডাইভিং, আমরা বলতে পারি যে একটি শেষ বিন্দু একটি URI, অর্থাত্ অক্ষরের একটি ক্রম যা একটি বিমূর্ত বা শারীরিক সম্পদ সনাক্ত করে। ইউনিফর্ম রিসোর্স আইডেন্টিফায়ার (ইউআরআই) কখনও কখনও একটি এন্ডপয়েন্ট বা ইউআরআইকে পাথ বলা হয়, যার অর্থ সম্পদের পথ। এই নিবন্ধটির উদ্দেশ্যে, আমরা URI শব্দটি ব্যবহার করব। প্রতিটি নির্দিষ্ট সম্পদ একটি অনন্য URI থাকতে হবে. সার্ভার ডেভেলপার নিশ্চিত করার জন্য দায়ী যে প্রতিটি সংস্থান সর্বদা তার নিজস্ব URI আছে। আমাদের উদাহরণে, আমরা ডেভেলপার, তাই আমরা যেভাবে জানি তা করব। রিলেশনাল ডাটাবেসের প্রাথমিক কী হিসাবে সংখ্যাসূচক শনাক্তকারীকে বরাদ্দ করা যেমন প্রায়শই প্রথাগত, তেমনি REST-এ প্রতিটি সংস্থানের নিজস্ব আইডি থাকে। REST-এ রিসোর্স আইডি প্রায়ই ডেটাবেসের রেকর্ডের আইডির সাথে মেলে যা রিসোর্স সম্পর্কে তথ্য সঞ্চয় করে। REST URI গুলি সাধারণত কিছু সম্পদ বর্ণনাকারী বিশেষ্যের বহুবচন দিয়ে শুরু হয়। উদাহরণ স্বরূপ, "
  • /গ্রাহক - সমস্ত উপলব্ধ গ্রাহকের ইউআরআই
  • /customers/23 — একটি নির্দিষ্ট গ্রাহকের URI, অর্থাৎ ID=23 সহ গ্রাহক
  • /customers/4 — একটি নির্দিষ্ট গ্রাহকের URI, অর্থাৎ ID=4 সহ গ্রাহক।
কিন্তু এখানেই শেষ নয়. আমরা অর্ডার যোগ করে URI প্রসারিত করতে পারি:
  • /customers/4/orders — গ্রাহক নং 4 দ্বারা করা সমস্ত অর্ডারের URI
  • /customers/1/orders/12 — অর্ডার নং 12 এর ইউআরআই গ্রাহক নং 1 দ্বারা তৈরি করা হয়েছে।
যদি আমরা আরও পণ্য যোগ করে সম্প্রসারণ চালিয়ে যাই, আমরা পেতে পারি:
  • /customers/1/orders/12/items — গ্রাহক নং 1 দ্বারা তৈরি ক্রম নং 12-এ সমস্ত পণ্যের তালিকার URI।
যেহেতু আমরা নেস্টিংয়ের মাত্রা যোগ করি, গুরুত্বপূর্ণ বিষয় হল ইউআরআইগুলিকে স্বজ্ঞাত করা।

HTTP পদ্ধতি

HTTP পদ্ধতি হল যেকোনো অক্ষরের একটি ক্রম (নিয়ন্ত্রণ অক্ষর এবং সীমানা ছাড়া), যা সম্পদের উপর সঞ্চালিত প্রধান ক্রিয়াকলাপের নির্দেশ করে। বেশ কিছু সাধারণ HTTP পদ্ধতি আছে। আমরা তাদের তালিকা করব যেগুলি RESTful পরিষেবাগুলিতে প্রায়শই ব্যবহৃত হয়:
  • GET — একটি নির্দিষ্ট সংস্থান সম্পর্কে তথ্য পান (এর আইডির মাধ্যমে) বা সম্পদের সংগ্রহ সম্পর্কে
  • পোস্ট - একটি নতুন সংস্থান তৈরি করুন
  • PUT - একটি সংস্থান পরিবর্তন করুন (এর আইডির মাধ্যমে)
  • মুছুন - একটি সংস্থান মুছুন (এর আইডির মাধ্যমে)

হেডার

অনুরোধ, সেইসাথে প্রতিক্রিয়া, HTTP হেডার ধারণ করে। তারা অনুরোধ (বা প্রতিক্রিয়া) সম্পর্কে অতিরিক্ত তথ্য প্রদান করে। শিরোলেখ হল কী-মানের জোড়া। আপনি উইকিপিডিয়াতে সবচেয়ে সাধারণ শিরোনামগুলির তালিকা দেখতে পারেন । REST হিসাবে, ক্লায়েন্টরা প্রায়ই সার্ভারে অনুরোধে একটি "স্বীকার করুন" শিরোনাম পাঠায়। এই শিরোনামটি সার্ভারকে জানাতে প্রয়োজন যে কোন ফর্ম্যাটে ক্লায়েন্ট একটি প্রতিক্রিয়া পাওয়ার আশা করে৷ MIME প্রকারের তালিকায় বিভিন্ন ফরম্যাট দেওয়া আছে। MIME (মাল্টিপারপাস ইন্টারনেট মেল এক্সটেনশন) তথ্য এনকোডিং এবং বার্তা ফরম্যাটিং করার জন্য একটি স্পেসিফিকেশন যাতে সেগুলি ইন্টারনেটের মাধ্যমে পাঠানো যায়। প্রতিটি MIME প্রকার একটি স্ল্যাশ দ্বারা পৃথক দুটি অংশ নিয়ে গঠিত — একটি প্রকার এবং উপপ্রকার। বিভিন্ন ধরনের ফাইলের জন্য MIME ধরনের উদাহরণ:
  • টেক্সট — টেক্সট/প্লেইন, টেক্সট/সিএসএস, টেক্সট/এইচটিএমএল
  • ইমেজ — ইমেজ/পিএনজি, ইমেজ/জেপিইজি, ইমেজ/জিআইএফ
  • অডিও — অডিও/ওয়াভ, অডিও/এমপিইজি
  • ভিডিও — video/mp4, video/ogg
  • অ্যাপ্লিকেশন — অ্যাপ্লিকেশন/জেসন, অ্যাপ্লিকেশন/পিডিএফ, অ্যাপ্লিকেশন/এক্সএমএল, অ্যাপ্লিকেশন/অক্টেট-স্ট্রিম
উদাহরণস্বরূপ, একটি অনুরোধের মতো একটি শিরোনাম থাকতে পারে:

Accept:application/json
এই শিরোনামটি সার্ভারকে বলে যে ক্লায়েন্ট JSON ফর্ম্যাটে একটি প্রতিক্রিয়া পাওয়ার প্রত্যাশা করে।

শরীরের অনুরোধ

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

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

একসাথে অনুরোধ করা

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

GET /customers/23
Accept : application/json, application/xml
JSON বা XML ফর্ম্যাটে গ্রাহক নং 23 সম্পর্কে তথ্য পান

POST /customers
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}
নিম্নলিখিত ক্ষেত্রগুলির সাথে একটি নতুন গ্রাহক তৈরি করুন:
নাম — Amigo
ইমেল — amigo@jr.com
টেলিফোন নম্বর — +1 (222) 333-4444

PUT /customers/1
{
  "name" : "Ben",
  "email" : "bigben@jr.com",
  "phone" : "+86 (868) 686-8686"
}
নিম্নরূপ গ্রাহক নং 1 সম্পাদনা করুন:
নাম — বেন
ইমেল — bigben@jr.com
টেলিফোন নম্বর — +86 (868) 686-8686

DELETE /customers/12/orders/6
সিস্টেম থেকে গ্রাহক নং 12 দ্বারা করা অর্ডার নং 6 মুছুন৷

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

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

HTTP প্রতিক্রিয়া কোড

আসুন HTTP প্রতিক্রিয়া কোডগুলিকে আরও বিশদে বিবেচনা করি। একটি HTTP স্ট্যাটাস কোড হল HTTP প্রোটোকলের মাধ্যমে করা অনুরোধের সার্ভার প্রতিক্রিয়ার প্রথম লাইনের অংশ। এটি একটি পূর্ণসংখ্যা যা তিনটি দশমিক সংখ্যা নিয়ে গঠিত। প্রথম সংখ্যাটি প্রতিক্রিয়া স্ট্যাটাস কোডের ক্লাস নির্দেশ করে। প্রতিক্রিয়া কোড সাধারণত ইংরেজিতে একটি ব্যাখ্যামূলক বাক্যাংশ দ্বারা অনুসরণ করা হয়, একটি স্থান দ্বারা পৃথক করা হয়। এই বাক্যাংশটি প্রতিক্রিয়ার জন্য একটি মানব-পাঠযোগ্য কারণ। উদাহরণ:
  • 201 তৈরি করা হয়েছে
  • 401 অননুমোদিত
  • 507 অপর্যাপ্ত সঞ্চয়স্থান
প্রতিক্রিয়া কোডটি ক্লায়েন্টকে অনুরোধের ফলাফল বলে এবং পরবর্তীতে কী পদক্ষেপ নিতে হবে তা নির্ধারণ করার অনুমতি দেয়। প্রতিক্রিয়া কোডগুলি বিভিন্ন শ্রেণী বা গোষ্ঠীতে বিভক্ত:
  • 1XX — তথ্যপূর্ণ
  • 2XX — এই কোডগুলি নির্দেশ করে যে ক্লায়েন্টের অনুরোধ সফলভাবে প্রাপ্ত এবং প্রক্রিয়া করা হয়েছে৷
  • 3XX — এই কোডগুলি ক্লায়েন্টকে জানায় যে একটি অতিরিক্ত অনুরোধ, সাধারণত একটি ভিন্ন URI-তে, সফলভাবে অপারেশন সম্পূর্ণ করার জন্য করা আবশ্যক
  • 4XX — ক্লায়েন্ট ত্রুটি। এই ধরনের কোডগুলি একটি ভুলভাবে তৈরি করা অনুরোধের ফলে হতে পারে। আরেকটি উদাহরণ হল সুপরিচিত "404 নট ফাউন্ড" কোড, যেটি ঘটতে পারে যখন কোনো ক্লায়েন্ট কোনো অস্তিত্বহীন সম্পদের অনুরোধ করে
  • 5XX — সার্ভার ত্রুটি। সার্ভার অপারেশনের ব্যর্থতার জন্য দায়ী হলে এই কোডগুলি ক্লায়েন্টকে ফেরত দেওয়া হয়
REST এর ওভারভিউ। পার্ট 3: স্প্রিং বুটে একটি আরামদায়ক পরিষেবা তৈরি করা
মন্তব্য
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION