প্রথম মডিউলটি আপনার একটি HTTP অনুরোধ তৈরি করে, এটি পাঠানো এবং একটি প্রতিক্রিয়া পাওয়ার সাথে শেষ হয়৷

আমরা ভবিষ্যতে আরও অনেকবার এটি করব। আমরা তৃতীয় পক্ষের সার্ভারে অনুরোধ পাঠাব। আমরা এমন আবেদন করব যেগুলি নিজেরাই এই ধরনের অনুরোধগুলি গ্রহণ করে এবং একটি প্রতিক্রিয়া ফেরত দেয়। আমরা অনুরোধ প্রক্রিয়াকরণের জন্য জটিল যুক্তি তৈরি করব।

অতএব, এই অনুরোধগুলির সাথে সম্পর্কিত সমস্ত কিছু পুঙ্খানুপুঙ্খভাবে অধ্যয়ন করা, বিস্তারিতভাবে বিশ্লেষণ করা ভাল হবে। যাতে আপনি অনুরোধটি কোথাও অনুলিপি করতে এবং এটি পুনরাবৃত্তি করতে পারেন না, তবে এটি কীভাবে কাজ করে তা সত্যিই খুঁজে বের করতে পারেন।

এটিই আমরা দ্বিতীয় মডিউলে করব। চলো যাই!

তত্ত্ব দিয়ে শুরু করা যাক।


REST API শেখা

REST API বেসিক

আপনি যদি প্রথম মডিউলে আপনার হোমওয়ার্ক করেন এবং ডকুমেন্টেশন অধ্যয়ন করেন, তাহলে আপনার সংক্ষিপ্ত রূপ API লক্ষ্য করা উচিত ছিল। প্রকৃতপক্ষে, এটি হল API ডকুমেন্টেশন যা ডেভেলপারদের প্রথমে অধ্যয়ন করা উচিত যদি তারা নেটওয়ার্কে কিছু পরিষেবা বা অ্যাপ্লিকেশনের সাথে মিথস্ক্রিয়া বুঝতে চায়।

API - অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস। এটি ক্লায়েন্ট এবং সার্ভার একে অপরের সাথে যোগাযোগ করতে পারে এমন উপায়গুলির একটি বিবরণ। আমরা API ডকুমেন্টেশন খুলি এবং সেখান থেকে শিখি কিভাবে সার্ভার থেকে প্রয়োজনীয় ডেটা পেতে হয়।

আমরা সবসময় এই মিথস্ক্রিয়া সহজ এবং বোধগম্য হতে চাই. এটি উভয় ডেভেলপার (নতুন পরিষেবা ডিজাইন করার সময় চাকাটি পুনরায় উদ্ভাবনের প্রয়োজন নেই) এবং ব্যবহারকারীদের (কোনও পরিষেবাটি পূর্বে পরিচিত পরিষেবাগুলির মতো একই নীতিতে কাজ করলে এটি শিখতে অনেক সহজ) কাজটিকে সহজ করে তোলে৷ এবং এখানে এটি একটি নতুন শব্দ মনে রাখা মূল্যবান - REST।

REST - প্রতিনিধিত্বমূলক রাষ্ট্র স্থানান্তরের সংক্ষিপ্ত রূপ। এটি খুব স্পষ্ট শোনাতে পারে না, তবে সহজভাবে বলতে গেলে, REST হল একটি ক্লায়েন্ট এবং একটি সার্ভারের মধ্যে মিথস্ক্রিয়া (তথ্য বিনিময়) একটি শৈলী।

এটি নিয়ম এবং প্রয়োজনীয়তার কিছু কঠোর সেট নয়। REST কোনো নির্দিষ্ট প্রোগ্রামিং ভাষা ব্যবহার করতে বাধ্য করে না, বা কঠোর নির্দেশিকা দিয়ে হাত বাঁধে না। REST কে একটি স্থাপত্য শৈলী বলা হয় এবং এটি 6 টি নীতি সংজ্ঞায়িত করে যা একটি সিস্টেম আর্কিটেকচারকে অবশ্যই মেনে চলতে হবে।

তদনুসারে, REST-এর নীতিগুলি বিবেচনায় নিয়ে একটি API তৈরি করা হয় তাকে REST API বলা হয়, এবং অ্যাপ্লিকেশনগুলিকে RESTful বলা হয়

আমরা ঠিক এই ধরনের আরামদায়ক অ্যাপ্লিকেশন তৈরি করব, তাই তারা এখনই যে নীতিগুলি মেনে চলবে তা নিয়ে আলোচনা করা মূল্যবান৷

  1. ক্লায়েন্ট-সার্ভার মডেল। নীতিটি ক্লায়েন্ট এবং সার্ভারের পৃথকীকরণ, তাদের প্রয়োজনের পার্থক্যকে সংজ্ঞায়িত করে। ক্লায়েন্টকে কীভাবে ডেটা সংরক্ষণ করা হয় তা নিয়ে চিন্তা করতে হবে না, প্রধান জিনিসটি অনুরোধের ভিত্তিতে জারি করা হয়। পরিবর্তে, সার্ভার ক্লায়েন্ট এই ডেটার সাথে কী করবে, কীভাবে এটি আরও প্রক্রিয়া করবে এবং এটি প্রদর্শন করবে তা চিন্তা করে না। এটি তাদের একে অপরের থেকে স্বাধীনভাবে বিকাশ করতে দেয় এবং সিস্টেমের মাপযোগ্যতা উন্নত করে।
  2. রাষ্ট্রহীনতা। এই নীতির মানে হল যে সার্ভারের এই ক্লায়েন্টের সাথে পূর্বের অভিজ্ঞতার উপর ভিত্তি করে প্রতিক্রিয়া "চিন্তা" করা উচিত নয়। যেকোনো অনুরোধ এমনভাবে করা হয় যাতে পূর্বের অনুরোধগুলি নির্বিশেষে তার প্রক্রিয়াকরণের জন্য প্রয়োজনীয় সমস্ত তথ্য থাকে।
  3. ক্যাশিং। ট্রান্সমিটেড ডাটা মিনিমাইজ করার জন্য ক্যাশিং মেকানিজম আছে। উদাহরণস্বরূপ, যদি কোনো পৃষ্ঠায় কোনো লোগো প্রদর্শিত হয়, তাহলে সার্ভার থেকে প্রতিবার অনুরোধ করার কোনো মানে হয় না। এটি প্রায়শই পরিবর্তন হয় না, এটি একবার পেতে এবং ক্লায়েন্টের কম্পিউটারে, ক্যাশে সংরক্ষণ করা যথেষ্ট হবে। কিন্তু যদি আমাদের গাড়ির বর্তমান গতি সম্পর্কে তথ্য পেতে হয়, তাহলে ক্যাশে কোনোভাবেই সাহায্য করবে না। এই নীতি নির্ধারণ করে যে সার্ভার দ্বারা প্রেরিত ডেটা ক্যাশেযোগ্য হিসাবে মনোনীত করা উচিত বা না।
  4. ইউনিফর্ম ইন্টারফেস। নীতিটি ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশনের একটি একক বিন্যাস সংজ্ঞায়িত করে। সমস্ত অনুরোধের কাঠামো একই হতে হবে। কে অনুরোধ করুক না কেন ডেটা একই ফর্মে পাঠাতে হবে।
  5. স্তরযুক্ত সিস্টেম। ক্লায়েন্ট এবং সার্ভার অগত্যা সরাসরি যোগাযোগ করে না। ডেটা ট্রান্সমিশন বিভিন্ন মধ্যবর্তী নোডের মধ্য দিয়ে যেতে পারে। এই ক্ষেত্রে, সিস্টেমটি এমনভাবে ডিজাইন করা হয়েছে যাতে ক্লায়েন্ট বা সার্ভার কেউই জানে না যে তারা চূড়ান্ত অ্যাপ্লিকেশন বা একটি মধ্যবর্তী নোডের সাথে ইন্টারঅ্যাক্ট করছে কিনা। এটি আপনাকে সার্ভারে লোডের ভারসাম্য বজায় রাখতে, স্কেলেবিলিটি বাড়াতে দেয়।
  6. চাহিদা অনুযায়ী কোড (ঐচ্ছিক) একমাত্র নীতি যা বাধ্যতামূলক নয়। এটি অনুসারে, ক্লায়েন্ট সার্ভার থেকে এক্সিকিউটেবল কোড ডাউনলোড করে তার কার্যকারিতা প্রসারিত করতে পারে (উদাহরণস্বরূপ, স্ক্রিপ্টগুলি)। এই ক্ষেত্রে, কোড শুধুমাত্র চাহিদার উপর কার্যকর করা উচিত।

খুব বেশি তত্ত্ব না?

এর অনুশীলন করা যাক.

একটি API অনুরোধ তৈরি করা হচ্ছে

আসুন AppMaster খুলি , এটি ব্যবহার করে একটি API অনুরোধ তৈরি করি এবং এই অনুরোধটি কীভাবে কাজ করে সে সম্পর্কে আরও ভালভাবে বুঝতে পারি।


API অনুরোধগুলি "বিজনেস লজিক" বিভাগে তৈরি করা হয়, "বহিরাগত API অনুরোধ" ট্যাবে।

এটি "+ নতুন API অনুরোধ" ক্লিক করার সময়।


নাম এবং বিবরণ যেকোনো কিছুতে সেট করা যেতে পারে, সেগুলি শুধুমাত্র আমাদের ব্যক্তিগত ব্যবহারের জন্য।

এর সত্যিই গুরুত্বপূর্ণ যে তথ্য মোকাবেলা করা যাক.

একটি অনুরোধ তৈরি করার জন্য ন্যূনতম প্রয়োজন তার পদ্ধতি এবং ঠিকানা (URL) উল্লেখ করা। শেষটা দিয়ে শুরু করা যাক।


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

এর ঠিকানায় ডেটা উল্লেখ করে, আমরা অনুরোধের পদ্ধতি (আপনি প্রকারটিও বলতে পারেন) নির্দেশ করে, অর্থাৎ, এই ডেটা দিয়ে আসলে কী করা দরকার তা আমরা নির্দেশ করি।

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

দেখা যাক অন্যান্য পদ্ধতি কি বিদ্যমান।


HTTP স্ট্যান্ডার্ড নিজেই ব্যবহার করা যেতে পারে এমন পদ্ধতির সংখ্যা সীমাবদ্ধ করে না। একই সময়ে, সামঞ্জস্য বজায় রাখার জন্য শুধুমাত্র কিছু সবচেয়ে মানক পদ্ধতি এখনও ব্যবহার করা হয়। অ্যাপমাস্টার এপিআই অনুরোধে 5টি ভিন্ন পদ্ধতি ব্যবহার করা যেতে পারে।

  • পান । এটা ইতিমধ্যে মোকাবেলা করা হয়েছে. পদ্ধতিটি একটি সংস্থানের বিধানের জন্য অনুরোধ করে এবং ডেটা গ্রহণ করে।
  • পোস্ট কোথাও থেকে ডেটা নিতে, আপনাকে প্রথমে এই ডেটা সেখানে রাখতে হবে। POST পদ্ধতি ঠিক তাই করে। সার্ভারে ডেটা পাঠায়, একটি সংস্থান তৈরি করে।
  • রাখুন POST পদ্ধতির মতই, কিন্তু এর কাজ হল ডেটা আপডেট করা। এটি নতুন ডেটা তৈরি করে না, তবে বিদ্যমান ডেটা প্রতিস্থাপন করে, এটি আপডেট করে।
  • মুছুন । নাম অনুসারে, এটি ডেটা মুছে ফেলে।
  • প্যাচ পদ্ধতিটি PUT-এর মতোই, তবে এটি সম্পূর্ণরূপে প্রতিস্থাপন না করে আংশিকভাবে ডেটা আপডেট করতে ব্যবহৃত হয়। উদাহরণস্বরূপ, প্যাচ পদ্ধতি ব্যবহার করে, আপনি একটি নিবন্ধের শিরোনাম পরিবর্তন করতে পারেন, বা কিছু প্যারামিটারের মান পরিবর্তন করতে পারেন।

এটা বিবেচনা করা গুরুত্বপূর্ণ যে সার্ভারটি পদ্ধতিতে নির্দিষ্ট করা ঠিক যা করার প্রয়োজন নেই। আমরা DELETE পদ্ধতিতে কিছু পৃষ্ঠার ঠিকানা পাঠাতে পারি, কিন্তু এর মানে এই নয় যে সার্ভার আসলে এটি মুছে দেবে। কিন্তু, বিশুদ্ধভাবে তাত্ত্বিকভাবে, তিনি GET কমান্ড দিয়ে এটি করতে পারেন। অথবা কিছু পরিবর্তন করবেন না, কিন্তু একই সময়ে POST এর প্রতিক্রিয়া হিসাবে ডেটা পাঠান। শুধুমাত্র কারণ বিকাশকারী এটিকে সেভাবে কনফিগার করেছে।

এখানেই REST খেলায় আসে, যা বলে যে আদেশ পালনে একমত হওয়ার, জগাখিচুড়ি বন্ধ করার এবং পদ্ধতিতে যা নির্দেশ করা হয়েছে ঠিক তা করার সময় এসেছে। খুব অন্তত, এটি প্রধান কাজ হওয়া উচিত (যদিও অগত্যা শুধুমাত্র একটি নয়)। যেমন, GET পদ্ধতি ব্যবহার করে একটি নিবন্ধের বিষয়বস্তু স্থানান্তর করার সময়, আপনি একই সময়ে এর ভিউয়ের সংখ্যা 1 দ্বারা বৃদ্ধি করতে পারেন।

সুতরাং, আমরা খুঁজে বের করেছি যে ডেটা কোথায় অবস্থিত এবং এটি দিয়ে কী করা যেতে পারে। এর আরও এগিয়ে যাওয়া যাক, অনুরোধের অন্যান্য উপাদানগুলি কী থাকতে পারে তা দেখা যাক।


URL Params. এমন পরিস্থিতিতে আছে যেখানে আমরা শুধুমাত্র URL এর কিছু অংশ জানি। একটি উদাহরণ হল Appmaster.io ওয়েবসাইটের নিবন্ধগুলি৷ সমস্ত নিবন্ধের শুরুর ঠিকানা একই - https://appmaster.io/en/blog/। কিন্তু তারপরে প্রতিটি নিবন্ধের নিজস্ব শিরোনাম রয়েছে এবং সেই অনুযায়ী, এই নির্দিষ্ট নিবন্ধটির সঠিক ইঙ্গিতের জন্য তার নিজস্ব পৃথক অংশ রয়েছে।

এই ধরনের পরিস্থিতিতে, URL Params ব্যবহার করা হয়। আমরা অবিলম্বে সাধারণ অংশ নির্ধারণ করি, এবং বাকিগুলি প্রক্রিয়ায় সিদ্ধান্ত নেওয়ার জন্য ছেড়ে দিই। ফলস্বরূপ, URLটি https://appmaster.io/ru/blog/:id/ আকারে লেখা হয়েছে

পরিচিত অংশটি যেমন আছে তেমন লেখা হয় এবং পরিবর্তনশীল অংশটি ":" চিহ্নের পরে স্থাপন করা হয়। এই পরিবর্তনশীল অংশের নাম (ইতিমধ্যে ":" ছাড়া) প্যারামিটারের তালিকায় যোগ করা হয়েছে। এই ক্ষেত্রে, বেশ কয়েকটি পরিবর্তনশীল অংশ থাকতে পারে এবং তাদের অবস্থান URL-এর যে কোনও জায়গায় রয়েছে।


জিজ্ঞাসা পরম . মনে আছে যখন আমরা প্রথম মডিউলে boredapi.com এ একটি অনুরোধ পাঠিয়েছিলাম? এবং ঠিকানা ছাড়াও, অতিরিক্ত ডেটা নির্ধারিত ছিল। যে প্রশ্ন ছিল পরম.

এগুলি URL-এর পরে লেখা হয় এবং একটি "?" দ্বারা এটি থেকে পৃথক করা হয়। চিহ্ন. প্যারামিটারের নাম, চিহ্ন “=” এবং প্যারামিটারের মান নিজেই নির্দেশিত হয়। যদি একাধিক পরামিতি একবারে ব্যবহার করা হয়, সেগুলিকে "&" চিহ্ন দ্বারা পৃথক করা হয়।

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

ক্যোয়ারী প্যারাম ব্যবহার করা হয় যখন ডেটা উৎস একই, কিন্তু ডেটা নিজেই আলাদা হতে পারে। উদাহরণস্বরূপ, বোরেডাপিতে করণীয়গুলির একটি বিশাল তালিকা রয়েছে। কিন্তু আমরা শুধুমাত্র সেগুলির প্রতি আগ্রহী ছিলাম যেগুলি একজন ব্যক্তির জন্য ছিল এবং এটিই আমরা অনুরোধের পরামিতিগুলিতে নির্দেশ করেছি৷

আরেকটি বিকল্প হল একটি অ্যাক্সেস কী। Alphavantage উল্লেখ করার সময় আপনি মডিউল 1 এ এই বিকল্পটি ব্যবহার করতে পারেন। রেজিস্ট্রেশন এবং অনুরোধের পরামিতিগুলিতে একটি ব্যক্তিগত কী পাঠানোর পরেই ডেটা প্রাপ্ত করা যেতে পারে।

আপনি ইন্টারনেটে যে পৃষ্ঠাগুলিতে যান সেগুলিতে মনোযোগ দিন, আপনি সম্ভবত সেগুলিতেও বিভিন্ন পরামিতি পাবেন। উদাহরণ স্বরূপ, Ventusky.com-এর আবহাওয়া পৃষ্ঠা খুলুন, কোয়েরি প্যারামিটারে অক্ষাংশ এবং দ্রাঘিমাংশের ভৌগলিক মানগুলি পাঠানো হয়।

হেডার শিরোনাম অনুরোধ করুন. সাধারণত হেডারে অনুরোধের (মেটা-তথ্য) সম্পর্কে পরিষেবার তথ্য থাকে। হেডার সার্ভারকে ক্লায়েন্ট সম্পর্কে আরও তথ্য পেতে অনুমতি দেয় যা ডেটার অনুরোধ করছে। কোন ব্রাউজারটি ব্যবহার করা হচ্ছে, কোন এনকোডিং প্রতিক্রিয়া প্রত্যাশিত, কোন ভাষায়, অনুরোধের সঠিক সময় এবং আরও অনেক কিছু সম্পর্কে হেডারগুলিতে তথ্য থাকতে পারে৷ সুরক্ষিত ডেটা অ্যাক্সেসের ক্ষেত্রে, শিরোনামগুলিতে একটি অনুমোদন কী থাকতে পারে।

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

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

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

একটি গুরুত্বপূর্ণ পার্থক্য প্রতিক্রিয়া অবস্থা.

স্ট্যাটাস কোড । এটি সার্ভারের প্রতিক্রিয়ার প্রথম লাইনে আসে। স্ট্যাটাসটি একটি তিন-সংখ্যার সংখ্যা (কোড নিজেই), তারপরে এটি ব্যাখ্যা করে একটি বাক্যাংশ।

স্ট্যাটাস কোডের মাধ্যমে আপনি অনুরোধের ফলাফল সম্পর্কে জানতে পারবেন এবং পরবর্তীতে কী পদক্ষেপ নেওয়া উচিত তা বুঝতে পারবেন।

সমস্ত সম্ভাব্য স্ট্যাটাস কোড 5টি ক্লাসে বিভক্ত। কোডের প্রথম সংখ্যা একটি নির্দিষ্ট শ্রেণীর অন্তর্গত নির্ধারণ করে। আসুন তাদের ভেঙ্গে ফেলি।

1xx — তথ্য কোড। অনুরোধের অগ্রগতি রিপোর্ট করুন। বাস্তব অনুশীলনে, তারা খুব কমই ব্যবহৃত হয়।

2xx - সাফল্যের কোড। তারা রিপোর্ট করে যে সবকিছু ঠিক আছে এবং অনুরোধটি সফলভাবে সম্পন্ন হয়েছে। একটি GET অনুরোধের প্রতিক্রিয়া হিসাবে, আমরা সাধারণত একটি 200 (OK) কোড পাওয়ার আশা করি। একটি সফল PUT অনুরোধ একটি 201 (তৈরি করা) কোড পাঠায়।

3xx — পুনঃনির্দেশ। নির্দেশ করুন যে অনুরোধটি অন্য ঠিকানায় পাঠানো উচিত। একটি উদাহরণ হল কোড 301 (স্থায়ীভাবে সরানো), নির্দেশ করে যে প্রয়োজনীয় ডেটা এখন একটি নতুন ঠিকানায় রয়েছে (নতুন ঠিকানাটি নিজেই অবস্থান শিরোনামে পাস করা হয়েছে)।

4xx — ক্লায়েন্ট এরর কোড। তাদের মধ্যে সবচেয়ে বিখ্যাত - 404 (খুঁজে পাওয়া যায়নি), রিপোর্ট করে যে নির্দিষ্ট ঠিকানায় কোন প্রয়োজনীয় তথ্য নেই। অন্যান্য সাধারণ ক্ষেত্রে: 400 (খারাপ অনুরোধ, অনুরোধে সিনট্যাক্স ত্রুটি), 401 (অনুমোদিত, অ্যাক্সেসের জন্য প্রমাণীকরণ প্রয়োজন), 403 (নিষিদ্ধ, অ্যাক্সেস অস্বীকার)।

5xx — সার্ভার ত্রুটি কোড। সার্ভার সাইডে একটি ত্রুটি রিপোর্ট করুন. একটি উদাহরণ হিসাবে: 500 (অভ্যন্তরীণ সার্ভার ত্রুটি, কোনো বোধগম্য ত্রুটি যা পরিচিত কোডের জন্য দায়ী করা যায় না), 503 (পরিষেবা অনুপলব্ধ, সার্ভারটি প্রযুক্তিগত কারণে অনুরোধটি প্রক্রিয়া করতে সাময়িকভাবে অক্ষম)

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


একটি নির্দিষ্ট প্রেক্ষাপট রয়েছে বলে ডেটার সাথে কীভাবে কাজ করবেন তা সাধারণত একজন মানুষের কাছে বেশ সুস্পষ্ট। ধরুন আমরা জানি যে 2 + 2 = 4। আমরা অনুমান করি যে এইগুলি সংখ্যা এবং যোগের ফলাফল অন্য একটি সংখ্যা হবে।

তবে এটি সংখ্যা নয়, পাঠ্য ডেটা হতে পারে। তারপর তাদের সংযোজনের ফলাফল হতে পারে স্ট্রিংগুলির সংমিশ্রণ এবং 2 + 2 "22" এ পরিণত হবে। এখানে, যাতে কম্পিউটারকে কিছু ভাবতে না হয়, ডাটা টাইপের সঠিক ইঙ্গিত রয়েছে। এবং একই সাথে, অন্যান্য কাজগুলি সমাধান করা হচ্ছে। উদাহরণস্বরূপ, ভুল তথ্য প্রবেশের বিরুদ্ধে সুরক্ষা প্রদান করা হয়; প্রাথমিকভাবে, একটি ফোন নম্বরের নম্বর প্রবেশের উদ্দেশ্যে ক্ষেত্রটিতে একটি ই-মেইল ঠিকানা নিবন্ধন করার কোন সুযোগ নেই।

এখানে অনেকগুলি বিভিন্ন ডেটা টাইপ রয়েছে, এখন আমরা সবচেয়ে মৌলিকগুলি বিবেচনা করব এবং কোর্সের আরও মডিউলগুলিতে আমরা বাকিগুলির সাথে পরিচিত হব।

স্ট্রিং — স্ট্রিং ডেটা টাইপ, কোনো বিশেষ বিন্যাস ছাড়াই সাধারণ পাঠ্য।

পূর্ণসংখ্যা - পূর্ণসংখ্যা ডেটা টাইপ। কাউন্টার বা গণনার জন্য ব্যবহার করা যেতে পারে যেখানে ভগ্নাংশ সংখ্যার প্রয়োজন নেই

ফ্লোট — ফ্লোটিং পয়েন্ট নম্বর। এটি ব্যবহার করা হয় যেখানে বর্ধিত নির্ভুলতা প্রয়োজন এবং পূর্ণসংখ্যার মান যথেষ্ট নয়।

এখানে একটি যৌক্তিক প্রশ্ন উঠতে পারে। এবং কেন সবসময় ফ্লোট ব্যবহার করবেন না, কেন আমাদের ইন্টিজার দরকার? কিন্তু বৃহত্তর নির্ভুলতা আরো সম্পদ প্রয়োজন. কিছু ছোট গণনার জন্য এটি সম্পূর্ণরূপে অদৃশ্য হতে পারে, তবে প্রচুর পরিমাণে ডেটার ক্ষেত্রে, একটি যুক্তিসঙ্গত ডেটা টাইপ ব্যবহার করা কম্পিউটিং শক্তি এবং ডিস্কের স্থানের প্রয়োজনীয়তা উল্লেখযোগ্যভাবে হ্রাস করতে পারে।

বুলিয়ান — বুলিয়ান ডেটা টাইপ। সহজতম ডেটা টাইপ। এটি দুটি মানগুলির একটি লাগে, যা সত্য বা মিথ্যা হিসাবে লেখা হয়। আপনি প্রায়ই 1 (সত্য) এবং 0 (মিথ্যা) আকারে উপাধি দেখতে পারেন।


বাড়ির কাজ

বাহ্যিক API অনুরোধ বিভাগে অ্যাপমাস্টারে তৈরি করে হোমওয়ার্ক থেকে প্রথম মডিউলে অনুরোধগুলি পুনরাবৃত্তি করুন।

  1. BoredAPI-তে একটি অনুরোধ তৈরি করুন। ডকুমেন্টেশন থেকে কমপক্ষে 5টি ভিন্ন প্যারামিটার উল্লেখ করুন। শুধুমাত্র প্রয়োজনীয় পরামিতি নির্দিষ্ট করে বিভিন্ন অনুরোধ জমা দিন।
  2. Alphavantage একটি অনুরোধ তৈরি করুন. একে অপরের সাথে সম্পর্কিত বিভিন্ন মুদ্রার হার পেতে পরামিতি ব্যবহার করুন।