এই নথিটি ঠিকানা যাচাইকরণ API থেকে বিভিন্ন প্রতিক্রিয়া পরিচালনা করার জন্য একটি ঠিকানা যাচাইকরণ সিস্টেম তৈরির একটি প্রক্রিয়া বর্ণনা করে। প্রতিক্রিয়াটি সঠিকভাবে ব্যবহার করার জন্য কীভাবে আপনার যুক্তি তৈরি করবেন, API থেকে অন্যান্য সংকেতগুলি তদন্ত করতে এবং কখন এবং কীভাবে আপনার গ্রাহকদের আরও তথ্যের জন্য প্রম্পট করবেন তা এটি কভার করে।
সাধারণভাবে API প্রতিক্রিয়া নিম্নলিখিত উপায়গুলি নির্ধারণ করে যেগুলি আপনার সিস্টেমকে একটি ঠিকানা পরিচালনা করা উচিত:
- ফিক্স - ঠিকানাটি নিম্নমানের। আপনি আরো তথ্যের জন্য অনুরোধ করা উচিত.
- নিশ্চিত করুন — ঠিকানা উচ্চ মানের, কিন্তু ইনপুট ঠিকানা থেকে পরিবর্তন আছে। আপনি নিশ্চিতকরণের জন্য অনুরোধ করতে পারেন।
- স্বীকার করুন — ঠিকানা উচ্চ মানের। আপনি প্রদত্ত ঠিকানা গ্রহণ করতে পারেন.
মূল উদ্দেশ্য
এই নথিটি আপনাকে API প্রতিক্রিয়া সেরা বিশ্লেষণ করতে এবং সরবরাহ করা ঠিকানাগুলির সাথে পরবর্তী পদক্ষেপগুলি নির্ধারণ করতে আপনার সিস্টেমটি সংশোধন করতে সহায়তা করে৷ নিম্নলিখিত সিউডোকোড একটি সম্ভাব্য প্রবাহ চিত্রিত করে।
if (the API response indicates significant problems in the address)
FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
CONFIRM - confirm with the user that the address is correct
else
ACCEPT - continue with the address returned by the API.
সঠিক যুক্তি আপনার পরিস্থিতির উপর নির্ভর করে - আরো বিস্তারিত জানার জন্য বাস্তবায়ন নির্দেশিকা দেখুন। আপনি আমাদের এই যুক্তির ওপেন সোর্স বাস্তবায়ন ব্যবহার করতে পারেন, যা এক্সটেন্ডেড কম্পোনেন্ট লাইব্রেরিতে রয়েছে।
ওয়ার্কফ্লো ওভারভিউ
নীচের সারণীটি আপনার সিস্টেমের জন্য দুটি ক্রিয়া সংক্ষিপ্ত করে:
- ফিক্স, নিশ্চিতকরণ, আচরণ গ্রহণের উপর ভিত্তি করে ব্যবহার করার জন্য কর্মপ্রবাহ ।
- প্রতিক্রিয়া থেকে পরীক্ষা করার জন্য প্রথম সংকেত । এখানে বর্ণিত সংকেতগুলি
verdict
সম্পত্তি থেকে আসে এবং এটি পরীক্ষা করার জন্য একমাত্র সংকেত নয় , তবে ঠিকানার গুণমানের একটি প্রাথমিক নির্দেশক প্রদান করে৷ প্রতিটি আচরণের ধরন এই নথির একটি বিভাগের সাথে মিলে যায় যাতে আরও সংকেত বর্ণনা করা হয় যা আপনাকে তদন্ত করতে হবে।
আপনার সিস্টেম আচরণ | |||
---|---|---|---|
ঠিকানা ঠিক করুন |
| ||
ঠিকানা নিশ্চিত করুন |
| ||
ঠিকানা গ্রহণ করুন | ঠিকানা যাচাইকরণ API প্রতিক্রিয়া একটি চমৎকার মানের ঠিকানা নির্দেশ করে।
|
বাস্তবায়ন নির্দেশিকা
আপনার সিস্টেম ঠিকানা যাচাইকরণ API থেকে সংকেতগুলিতে কীভাবে সাড়া দেয় তা ডিজাইন করার সময়, নিম্নলিখিত সুপারিশগুলি আপনাকে আরও কার্যকর প্রতিক্রিয়া মডেল তৈরি করতে সহায়তা করতে পারে। যাইহোক, এইগুলি শুধুমাত্র সুপারিশ, তাই মনে রাখবেন যে আপনার বাস্তবায়ন আপনার ব্যবসার মডেল অনুসারে হওয়া উচিত।
নির্দেশনা | বিস্তারিত | |
---|---|---|
ঝুঁকির স্তর | সংশোধনের জন্য অনুরোধ করা এবং প্রবেশ করা ঠিকানাটি গ্রহণ করার মধ্যে ভারসাম্য বজায় রাখার সময় আপনার পরিস্থিতির জন্য সহনশীলতার মাত্রা বিবেচনা করুন। | ঠিকানা যাচাইকরণ API বিভিন্ন ধরণের সংকেত প্রদান করে যা আপনি আপনার বৈধকরণ প্রক্রিয়াকে অপ্টিমাইজ করতে আপনার ঝুঁকির স্তরের সাথে অন্তর্ভুক্ত করতে পারেন। উদাহরণস্বরূপ, যদি একটি ঠিকানায় একটি অনিশ্চিত রাস্তার নম্বর থাকে, আপনি এখনও এটি গ্রহণ করতে পারেন৷ অন্যদিকে, যদি আপনার ব্যবসায়িক ক্রিয়াকলাপের জন্য আরও সঠিক ঠিকানার প্রয়োজন হয়, আপনি আপনার ব্যবহারকারীকে অনুরোধ করতে পারেন। একটি উদাহরণের জন্য যা যেকোনো একটি বিভাগে পড়তে পারে, অ্যাসেপ্ট অ্যাড্রেস-এ নন-ইউএস অপ্রমাণিত রাস্তার নম্বর দেখুন - উদাহরণ । |
ঠিকানা গ্রহণ করুন | গ্রাহক প্রম্পটে সাড়া না দিলে আপনার সিস্টেমকে আসল এন্ট্রি গ্রহণ করার অনুমতি দেওয়া একটি ভাল অভ্যাস। | এই ক্ষেত্রে, গ্রাহক সিস্টেমে নেই এমন একটি ঠিকানা লিখতে পারে, যেমন নতুন নির্মাণের জন্য। |
মতামত প্রদান | আপনি যখন একটি ঠিকানা যাচাইকরণের অনুরোধ পুনরায় ইস্যু করেন, আপনি | এটি Google কে জানতে দেয় যে আপনি চূড়ান্ত প্রতিক্রিয়া কীভাবে পরিচালনা করেছেন৷ আপডেট করা ঠিকানা হ্যান্ডেল দেখুন। |
একটি ঠিকানা ঠিক করুন
একটি ঠিকানা ঠিক করুন যখন ফলাফল স্পষ্টভাবে নির্দেশ করে যে ঠিকানাটি বিতরণযোগ্য নয়। তারপরে আপনার সিস্টেম গ্রাহককে প্রয়োজনীয় তথ্য প্রদানের জন্য অনুরোধ করতে পারে, তারপরে আপনি একটি বিতরণযোগ্য ঠিকানা পেতে আপনার ওয়ার্কফ্লো পুনরায় জারি করবেন।
সংকেত ঠিক করুন
ঠিকানা ঠিক করা উচিত কিনা তা জানাতে ঠিকানা যাচাইকরণ API আপনাকে জানাতে বেশ কয়েকটি সংকেত প্রদান করে।
1. বৈধকরণ গ্রানুলারিটি এবং অনুপস্থিত উপাদান
এই দুটি সংকেত একটি সমস্যাযুক্ত ঠিকানার সর্বোত্তম ইঙ্গিত প্রদান করে:
- যখনই
validationGranularity
ক্ষেত্রটিOTHER
হয়, আপনার সিস্টেমের ঠিকানা উপাদান সংকেতগুলি তদন্ত করা উচিত যেখানে ত্রুটি ঘটেছে এবং কীভাবে এটি ঠিক করা যায় সে সম্পর্কে আরও জানতে। - যখনই পোস্ট-প্রসেসড
address
অবজেক্ট একটিmissingComponentTypes
ক্ষেত্র প্রদান করে, আপনার সিস্টেমটি সেই উপাদানটির জন্য পরীক্ষা করা উচিত। অনুপস্থিত উপাদানগুলিও একটি ঠিকানাকে অসম্পূর্ণ এবং অ-প্রদানযোগ্য করে তোলে।
2. অন্যান্য সংকেত
ঠিকানা যাচাইকরণ API নির্দিষ্ট সমস্যাগুলি নির্ণয় করতে সহায়তা করার জন্য অন্যান্য সংকেতও সরবরাহ করে:
সন্দেহজনক উপাদান | যখন একটি উপাদানের জন্য নিশ্চিতকরণ স্তরের enum হয় UNCOMFIRMED_AND_SUSPICIOUS , তখন সম্ভবত উপাদানটি ভুল। |
---|---|
অমীমাংসিত উপাদান | একটি অমীমাংসিত টোকেন হল ইনপুটের একটি অংশ যা একটি ঠিকানার বৈধ অংশ হিসাবে স্বীকৃত নয়৷ |
3. মার্কিন ঠিকানা সংকেত
শুধুমাত্র মার্কিন ঠিকানাগুলির জন্য প্রযোজ্য কিছু ক্ষেত্র একটি দরকারী সংকেত প্রদান করে যে ঠিকানাটি বিতরণযোগ্য নয় এবং ঠিক করা উচিত। একটি ঠিকানা যা ফিক্সিং প্রয়োজন, আপনি নিম্নলিখিত দেখতে হবে:
dpvConfirmation | হয় N , D , অথবা খালি৷ |
---|
dpvConfirmation
এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।
একটি ঠিকানা নিশ্চিত করুন
আপনি একটি ঠিকানা নিশ্চিত করেন যখন রায় নির্দেশ করে যে ঠিকানা যাচাইকরণ API হয় অনুমান করেছে বা একটি বৈধ ঠিকানা তৈরি করার জন্য ঠিকানা উপাদানগুলিতে পরিবর্তন করেছে৷ এই ক্ষেত্রে, আপনার কাছে একটি ডেলিভারিযোগ্য ঠিকানা আছে, কিন্তু আপনি আরও বেশি আত্মবিশ্বাস পছন্দ করেন যে ফলাফলের ঠিকানাটি গ্রাহকের উদ্দেশ্য।
গ্রাহককে সঠিক প্রম্পটিং প্রদান করতে, আপনার যুক্তিটি পরিসেবা দ্বারা পতাকাঙ্কিত উপাদানগুলিকে চিহ্নিত করবে যাতে inferred
, replaced
, বা spellCorrected
কম্পোনেন্টে কোন অ্যাকশন বা ফ্ল্যাগ এপিআই প্রয়োগ করা হয় তা নির্ধারণ করে। রেফারেন্সে AddressComponent দেখুন।
সংকেত নিশ্চিত করুন
ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।
1. বৈধকরণ গ্রানুলারিটি
ROUTE
বা এর চেয়ে ভালোর একটি validationGranularity
গ্রহণযোগ্য, কিন্তু হয় PREMISE বা SUBPREMISE সরবরাহযোগ্যতার একটি শক্তিশালী সংকেত প্রদান করে।
2. অন্যান্য সংকেত
গ্রাহকের সাথে ঠিকানা এন্ট্রি নিশ্চিত করার সিদ্ধান্ত নেওয়ার সময়, কোন উপাদানগুলি তদন্ত করতে হবে তা নির্ধারণ করতে রায়টি নিম্নলিখিতগুলিও প্রদান করে:
অনুমানকৃত তথ্য | যখন hasInferredComponents ক্ষেত্রটি true হয়, তখন আপনি জানেন যে API তথ্যে ভরা এটি অন্যান্য ঠিকানা উপাদান থেকে সংগ্রহ করেছে। |
---|---|
প্রতিস্থাপিত ডেটা | যখন hasReplacedComponents ক্ষেত্র true হয়, তখন API ঠিকানাটিকে বৈধ বলে মনে করা ডেটা দিয়ে প্রবেশ করা ডেটা প্রতিস্থাপন করে। |
3. মার্কিন ঠিকানা সংকেত
শুধুমাত্র মার্কিন ঠিকানার জন্য প্রযোজ্য কিছু ক্ষেত্র নির্দেশ করে যে আপনার যুক্তি গ্রাহকের সাথে বিশদ বিবরণ নিশ্চিত করা উচিত। নিম্নলিখিত যে কোনো একটি প্রযোজ্য:
dpvConfirmation | S |
---|---|
ঠিকানার প্রতিক্রিয়া | subpremise এর মান সহ missingComponentType ক্ষেত্র রয়েছে। |
একটি ঠিকানা গ্রহণ করুন
আপনি একটি ঠিকানা গ্রহণ করেন যখন রায় উচ্চ মাত্রার আত্মবিশ্বাস প্রদান করে যে ঠিকানাটি বিতরণযোগ্য এবং ডাউনস্ট্রীম প্রক্রিয়ায় গ্রাহকের মিথস্ক্রিয়া ছাড়াই ব্যবহার করা যেতে পারে।
সংকেত গ্রহণ করুন
ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।
1. বৈধকরণ গ্রানুলারিটি
PREMISE
বা তার চেয়ে ভালোর একটি validationGranularity
গ্রহণযোগ্য, কিন্তু কিছু ক্ষেত্রে, ROUTE
এখনও একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে।
2. অন্যান্য সংকেত
একটি উচ্চ মানের ঠিকানার জন্য একটি রায় নিম্নলিখিত প্রদান করা উচিত:
- কোনও প্রতিস্থাপিত ডেটা নেই । এই ক্ষেত্রে,
hasReplacedComponents: FALSE
। - কোন অনুমানকৃত উপাদান নেই । এই ক্ষেত্রে,
hasInferredComponents: FALSE
।
3. মার্কিন ঠিকানা সংকেত
শুধুমাত্র মার্কিন ঠিকানার জন্য প্রযোজ্য কিছু ক্ষেত্র একটি উচ্চ মানের ঠিকানা নির্দেশ করে যেটি সরবরাহ করা যেতে পারে। একটি গ্রহণযোগ্য মার্কিন ঠিকানার জন্য, আপনাকে নিম্নলিখিতগুলি দেখতে হবে:
dpvConfirmation | Y |
---|
এই নথিটি ঠিকানা যাচাইকরণ API থেকে বিভিন্ন প্রতিক্রিয়া পরিচালনা করার জন্য একটি ঠিকানা যাচাইকরণ সিস্টেম তৈরির একটি প্রক্রিয়া বর্ণনা করে। প্রতিক্রিয়াটি সঠিকভাবে ব্যবহার করার জন্য কীভাবে আপনার যুক্তি তৈরি করবেন, API থেকে অন্যান্য সংকেতগুলি তদন্ত করতে এবং কখন এবং কীভাবে আপনার গ্রাহকদের আরও তথ্যের জন্য প্রম্পট করবেন তা এটি কভার করে।
সাধারণভাবে API প্রতিক্রিয়া নিম্নলিখিত উপায়গুলি নির্ধারণ করে যেগুলি আপনার সিস্টেমকে একটি ঠিকানা পরিচালনা করা উচিত:
- ফিক্স - ঠিকানাটি নিম্নমানের। আপনি আরো তথ্যের জন্য অনুরোধ করা উচিত.
- নিশ্চিত করুন — ঠিকানা উচ্চ মানের, কিন্তু ইনপুট ঠিকানা থেকে পরিবর্তন আছে। আপনি নিশ্চিতকরণের জন্য অনুরোধ করতে পারেন।
- স্বীকার করুন — ঠিকানা উচ্চ মানের। আপনি প্রদত্ত ঠিকানা গ্রহণ করতে পারেন.
মূল উদ্দেশ্য
এই নথিটি আপনাকে API প্রতিক্রিয়া সেরা বিশ্লেষণ করতে এবং সরবরাহ করা ঠিকানাগুলির সাথে পরবর্তী পদক্ষেপগুলি নির্ধারণ করতে আপনার সিস্টেমটি সংশোধন করতে সহায়তা করে৷ নিম্নলিখিত সিউডোকোড একটি সম্ভাব্য প্রবাহ চিত্রিত করে।
if (the API response indicates significant problems in the address)
FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
CONFIRM - confirm with the user that the address is correct
else
ACCEPT - continue with the address returned by the API.
সঠিক যুক্তি আপনার পরিস্থিতির উপর নির্ভর করে - আরো বিস্তারিত জানার জন্য বাস্তবায়ন নির্দেশিকা দেখুন। আপনি আমাদের এই যুক্তির ওপেন সোর্স বাস্তবায়ন ব্যবহার করতে পারেন, যা এক্সটেন্ডেড কম্পোনেন্ট লাইব্রেরিতে রয়েছে।
ওয়ার্কফ্লো ওভারভিউ
নীচের টেবিলটি আপনার সিস্টেমের জন্য দুটি কর্মের সংক্ষিপ্ত বিবরণ দেয়:
- ফিক্স, নিশ্চিতকরণ, আচরণ গ্রহণের উপর ভিত্তি করে ব্যবহার করার জন্য কর্মপ্রবাহ ।
- প্রতিক্রিয়া থেকে পরীক্ষা করার জন্য প্রথম সংকেত । এখানে বর্ণিত সংকেতগুলি
verdict
সম্পত্তি থেকে আসে এবং এটি পরীক্ষা করার জন্য একমাত্র সংকেত নয় , তবে ঠিকানার গুণমানের একটি প্রাথমিক নির্দেশক প্রদান করে৷ প্রতিটি আচরণের ধরন এই নথির একটি বিভাগের সাথে মিলে যায় যাতে আরও সংকেত বর্ণনা করা হয় যা আপনাকে তদন্ত করতে হবে।
আপনার সিস্টেম আচরণ | |||
---|---|---|---|
ঠিকানা ঠিক করুন |
| ||
ঠিকানা নিশ্চিত করুন |
| ||
ঠিকানা গ্রহণ করুন | ঠিকানা যাচাইকরণ API প্রতিক্রিয়া একটি চমৎকার মানের ঠিকানা নির্দেশ করে।
|
বাস্তবায়ন নির্দেশিকা
আপনার সিস্টেম ঠিকানা যাচাইকরণ API থেকে সংকেতগুলিতে কীভাবে সাড়া দেয় তা ডিজাইন করার সময়, নিম্নলিখিত সুপারিশগুলি আপনাকে আরও কার্যকর প্রতিক্রিয়া মডেল তৈরি করতে সহায়তা করতে পারে। যাইহোক, এইগুলি শুধুমাত্র সুপারিশ, তাই মনে রাখবেন যে আপনার বাস্তবায়ন আপনার ব্যবসার মডেল অনুসারে হওয়া উচিত।
নির্দেশনা | বিস্তারিত | |
---|---|---|
ঝুঁকির স্তর | সংশোধনের জন্য অনুরোধ করা এবং প্রবেশ করা ঠিকানাটি গ্রহণ করার মধ্যে ভারসাম্য বজায় রাখার সময় আপনার পরিস্থিতির জন্য সহনশীলতার মাত্রা বিবেচনা করুন। | ঠিকানা যাচাইকরণ API বিভিন্ন ধরণের সংকেত প্রদান করে যা আপনি আপনার বৈধকরণ প্রক্রিয়াকে অপ্টিমাইজ করতে আপনার ঝুঁকির স্তরের সাথে অন্তর্ভুক্ত করতে পারেন। উদাহরণস্বরূপ, যদি একটি ঠিকানায় একটি অনিশ্চিত রাস্তার নম্বর থাকে, আপনি এখনও এটি গ্রহণ করতে পারেন৷ অন্যদিকে, যদি আপনার ব্যবসায়িক ক্রিয়াকলাপের জন্য আরও সঠিক ঠিকানার প্রয়োজন হয়, আপনি আপনার ব্যবহারকারীকে অনুরোধ করতে পারেন। একটি উদাহরণের জন্য যা যেকোনো একটি বিভাগে পড়তে পারে, অ্যাসেপ্ট অ্যাড্রেস-এ নন-ইউএস অপ্রমাণিত রাস্তার নম্বর দেখুন - উদাহরণ । |
ঠিকানা গ্রহণ করুন | গ্রাহক প্রম্পটে সাড়া না দিলে আপনার সিস্টেমকে আসল এন্ট্রি গ্রহণ করার অনুমতি দেওয়া একটি ভাল অভ্যাস। | এই ক্ষেত্রে, গ্রাহক সিস্টেমে নেই এমন একটি ঠিকানা লিখতে পারে, যেমন নতুন নির্মাণের জন্য। |
মতামত প্রদান | আপনি যখন একটি ঠিকানা যাচাইকরণের অনুরোধ পুনরায় ইস্যু করেন, আপনি | এটি Google কে জানতে দেয় যে আপনি চূড়ান্ত প্রতিক্রিয়া কীভাবে পরিচালনা করেছেন৷ আপডেট করা ঠিকানা হ্যান্ডেল দেখুন। |
একটি ঠিকানা ঠিক করুন
একটি ঠিকানা ঠিক করুন যখন ফলাফল স্পষ্টভাবে নির্দেশ করে যে ঠিকানাটি বিতরণযোগ্য নয়। তারপরে আপনার সিস্টেম গ্রাহককে প্রয়োজনীয় তথ্য প্রদানের জন্য অনুরোধ করতে পারে, তারপরে আপনি একটি বিতরণযোগ্য ঠিকানা পেতে আপনার ওয়ার্কফ্লো পুনরায় জারি করবেন।
সংকেত ঠিক করুন
ঠিকানা ঠিক করা উচিত কিনা তা জানাতে ঠিকানা যাচাইকরণ API আপনাকে জানাতে বেশ কয়েকটি সংকেত প্রদান করে।
1. বৈধকরণ গ্রানুলারিটি এবং অনুপস্থিত উপাদান
এই দুটি সংকেত একটি সমস্যাযুক্ত ঠিকানার সর্বোত্তম ইঙ্গিত প্রদান করে:
- যখনই
validationGranularity
ক্ষেত্রটিOTHER
হয়, আপনার সিস্টেমের ঠিকানা উপাদান সংকেতগুলি তদন্ত করা উচিত যেখানে ত্রুটি ঘটেছে এবং কীভাবে এটি ঠিক করা যায় সে সম্পর্কে আরও জানতে। - যখনই পোস্ট-প্রসেসড
address
অবজেক্ট একটিmissingComponentTypes
ক্ষেত্র প্রদান করে, আপনার সিস্টেমটি সেই উপাদানটির জন্য পরীক্ষা করা উচিত। অনুপস্থিত উপাদানগুলিও একটি ঠিকানাকে অসম্পূর্ণ এবং অ-প্রদানযোগ্য করে তোলে।
2. অন্যান্য সংকেত
ঠিকানা যাচাইকরণ API নির্দিষ্ট সমস্যাগুলি নির্ণয় করতে সহায়তা করার জন্য অন্যান্য সংকেতও সরবরাহ করে:
সন্দেহজনক উপাদান | যখন একটি উপাদানের জন্য নিশ্চিতকরণ স্তরের enum হয় UNCOMFIRMED_AND_SUSPICIOUS , তখন সম্ভবত উপাদানটি ভুল। |
---|---|
অমীমাংসিত উপাদান | একটি অমীমাংসিত টোকেন হল ইনপুটের একটি অংশ যা একটি ঠিকানার বৈধ অংশ হিসাবে স্বীকৃত নয়৷ |
3. মার্কিন ঠিকানা সংকেত
শুধুমাত্র মার্কিন ঠিকানাগুলির জন্য প্রযোজ্য কিছু ক্ষেত্র একটি দরকারী সংকেত প্রদান করে যে ঠিকানাটি বিতরণযোগ্য নয় এবং ঠিক করা উচিত। একটি ঠিকানা যা ফিক্সিং প্রয়োজন, আপনি নিম্নলিখিত দেখতে হবে:
dpvConfirmation | হয় N , D , অথবা খালি৷ |
---|
dpvConfirmation
এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।
একটি ঠিকানা নিশ্চিত করুন
আপনি একটি ঠিকানা নিশ্চিত করেন যখন রায় নির্দেশ করে যে ঠিকানা যাচাইকরণ API হয় অনুমান করেছে বা একটি বৈধ ঠিকানা তৈরি করার জন্য ঠিকানা উপাদানগুলিতে পরিবর্তন করেছে৷ এই ক্ষেত্রে, আপনার কাছে একটি ডেলিভারিযোগ্য ঠিকানা আছে, কিন্তু আপনি আরও বেশি আত্মবিশ্বাস পছন্দ করেন যে ফলাফলের ঠিকানাটি গ্রাহকের উদ্দেশ্য।
গ্রাহককে সঠিক প্রম্পটিং প্রদান করতে, আপনার যুক্তিটি পরিসেবা দ্বারা পতাকাঙ্কিত উপাদানগুলিকে চিহ্নিত করবে যাতে inferred
, replaced
, বা spellCorrected
কম্পোনেন্টে কোন অ্যাকশন বা ফ্ল্যাগ এপিআই প্রয়োগ করা হয় তা নির্ধারণ করে। রেফারেন্সে AddressComponent দেখুন।
সংকেত নিশ্চিত করুন
ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।
1. বৈধকরণ গ্রানুলারিটি
ROUTE
বা এর চেয়ে ভালোর একটি validationGranularity
গ্রহণযোগ্য, কিন্তু হয় PREMISE বা SUBPREMISE সরবরাহযোগ্যতার একটি শক্তিশালী সংকেত প্রদান করে।
2. অন্যান্য সংকেত
গ্রাহকের সাথে ঠিকানা এন্ট্রি নিশ্চিত করার সিদ্ধান্ত নেওয়ার সময়, কোন উপাদানগুলি তদন্ত করতে হবে তা নির্ধারণ করতে রায়টি নিম্নলিখিতগুলিও প্রদান করে:
অনুমানকৃত তথ্য | যখন hasInferredComponents ক্ষেত্রটি true হয়, তখন আপনি জানেন যে API তথ্যে ভরা এটি অন্যান্য ঠিকানা উপাদান থেকে সংগ্রহ করেছে। |
---|---|
প্রতিস্থাপিত ডেটা | যখন hasReplacedComponents ক্ষেত্র true হয়, তখন API ঠিকানাটিকে বৈধ বলে মনে করা ডেটা দিয়ে প্রবেশ করা ডেটা প্রতিস্থাপন করে। |
3. মার্কিন ঠিকানা সংকেত
শুধুমাত্র মার্কিন ঠিকানার জন্য প্রযোজ্য কিছু ক্ষেত্র নির্দেশ করে যে আপনার যুক্তি গ্রাহকের সাথে বিশদ বিবরণ নিশ্চিত করা উচিত। নিম্নলিখিত যে কোনো একটি প্রযোজ্য:
dpvConfirmation | S |
---|---|
ঠিকানার প্রতিক্রিয়া | subpremise এর মান সহ missingComponentType ক্ষেত্র রয়েছে। |
একটি ঠিকানা গ্রহণ করুন
আপনি একটি ঠিকানা গ্রহণ করেন যখন রায় উচ্চ মাত্রার আত্মবিশ্বাস প্রদান করে যে ঠিকানাটি বিতরণযোগ্য এবং ডাউনস্ট্রীম প্রক্রিয়ায় গ্রাহকের মিথস্ক্রিয়া ছাড়াই ব্যবহার করা যেতে পারে।
সংকেত গ্রহণ করুন
ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।
1. বৈধকরণ গ্রানুলারিটি
PREMISE
বা তার চেয়ে ভালোর একটি validationGranularity
গ্রহণযোগ্য, কিন্তু কিছু ক্ষেত্রে, ROUTE
এখনও একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে।
2. অন্যান্য সংকেত
একটি উচ্চ মানের ঠিকানার জন্য একটি রায় নিম্নলিখিত প্রদান করা উচিত:
- কোনও প্রতিস্থাপিত ডেটা নেই । এই ক্ষেত্রে,
hasReplacedComponents: FALSE
। - কোন অনুমানকৃত উপাদান নেই । এই ক্ষেত্রে,
hasInferredComponents: FALSE
।
3. মার্কিন ঠিকানা সংকেত
শুধুমাত্র মার্কিন ঠিকানার জন্য প্রযোজ্য কিছু ক্ষেত্র একটি উচ্চ মানের ঠিকানা নির্দেশ করে যেটি সরবরাহ করা যেতে পারে। একটি গ্রহণযোগ্য মার্কিন ঠিকানার জন্য, আপনাকে নিম্নলিখিতগুলি দেখতে হবে:
dpvConfirmation | Y |
---|