আপনার বৈধতা যুক্তি তৈরি করুন

এই নথিটি ঠিকানা যাচাইকরণ 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.

সঠিক যুক্তি আপনার পরিস্থিতির উপর নির্ভর করে - আরো বিস্তারিত জানার জন্য বাস্তবায়ন নির্দেশিকা দেখুন। আপনি আমাদের এই যুক্তির ওপেন সোর্স বাস্তবায়ন ব্যবহার করতে পারেন, যা এক্সটেন্ডেড কম্পোনেন্ট লাইব্রেরিতে রয়েছে।

ওয়ার্কফ্লো ওভারভিউ

নীচের টেবিলটি আপনার সিস্টেমের জন্য দুটি কর্মের সংক্ষিপ্ত বিবরণ দেয়:

  1. ফিক্স, নিশ্চিতকরণ, আচরণ গ্রহণের উপর ভিত্তি করে ব্যবহার করার জন্য কর্মপ্রবাহ
  2. প্রতিক্রিয়া থেকে পরীক্ষা করার জন্য প্রথম সংকেত । এখানে বর্ণিত সংকেতগুলি verdict সম্পত্তি থেকে আসে এবং এটি পরীক্ষা করার জন্য একমাত্র সংকেত নয় , তবে ঠিকানার গুণমানের একটি প্রাথমিক নির্দেশক প্রদান করে৷ প্রতিটি আচরণের ধরন এই নথির একটি বিভাগের সাথে মিলে যায় যাতে আরও সংকেত বর্ণনা করা হয় যা আপনাকে তদন্ত করতে হবে।
আপনার সিস্টেম আচরণ
ঠিকানা ঠিক করুন

verdict প্রতিক্রিয়া নির্দেশ করে গুরুত্বপূর্ণ অনুপস্থিত তথ্য যা প্রদান করা উচিত। ঠিকানা যাচাইকরণ API দ্বারা প্রত্যাবর্তিত ঠিকানা বিতরণযোগ্য মানের নাও হতে পারে।

কর্মপ্রবাহ

  1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
  2. ঠিকানা সমস্যা ঠিক করতে গ্রাহককে অনুরোধ করুন।
  3. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
  4. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
  5. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত যে কোনো একটি প্রযোজ্য:

ঠিকানা নিশ্চিত করুন

verdict প্রতিক্রিয়া একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে, কিন্তু মূল ইনপুটে পরিবর্তন করেছে: অনুমানকারী ডেটা যা হয় বানান সংশোধন করা হয়েছে, বা ডেটা যা নিশ্চিত করা যেতে পারে।

কর্মপ্রবাহ

  1. সংশোধন প্রয়োজন:
    1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
    2. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
    3. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
    4. ঠিকানা দিয়ে এগিয়ে যান।
  2. কোন সংশোধনের প্রয়োজন নেই:
    1. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
    2. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত সব প্রযোজ্য:

  • validationGranularity এর মধ্যে ROUTE বা আরও ভাল আছে। গ্রানুলিটি মান দেখুন।
  • addressComplete সম্পূর্ণ true
  • hasInferredComponents ক্ষেত্রটি true বা hasReplacedComponents ক্ষেত্রটি true
ঠিকানা গ্রহণ করুন

ঠিকানা যাচাইকরণ API প্রতিক্রিয়া একটি চমৎকার মানের ঠিকানা নির্দেশ করে।

কর্মপ্রবাহ

ফেরত ঠিকানা দিয়ে এগিয়ে যান.

রায় সংকেত

নিম্নলিখিত সব প্রযোজ্য:

  • validationGranularity এর মধ্যে PREMISE বা আরও ভালো থাকে। গ্রানুলিটি মান দেখুন।
  • addressComplete সম্পূর্ণ true
  • কোন অনুমান বা প্রতিস্থাপিত উপাদান.

বাস্তবায়ন নির্দেশিকা

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

নির্দেশনা বিস্তারিত
ঝুঁকির স্তর

সংশোধনের জন্য অনুরোধ করা এবং প্রবেশ করা ঠিকানাটি গ্রহণ করার মধ্যে ভারসাম্য বজায় রাখার সময় আপনার পরিস্থিতির জন্য সহনশীলতার মাত্রা বিবেচনা করুন।

ঠিকানা যাচাইকরণ API বিভিন্ন ধরণের সংকেত প্রদান করে যা আপনি আপনার বৈধকরণ প্রক্রিয়াকে অপ্টিমাইজ করতে আপনার ঝুঁকির স্তরের সাথে অন্তর্ভুক্ত করতে পারেন।

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

ঠিকানা গ্রহণ করুন

গ্রাহক প্রম্পটে সাড়া না দিলে আপনার সিস্টেমকে আসল এন্ট্রি গ্রহণ করার অনুমতি দেওয়া একটি ভাল অভ্যাস।

এই ক্ষেত্রে, গ্রাহক সিস্টেমে নেই এমন একটি ঠিকানা লিখতে পারে, যেমন নতুন নির্মাণের জন্য।

মতামত প্রদান

আপনি যখন একটি ঠিকানা যাচাইকরণের অনুরোধ পুনরায় ইস্যু করেন, আপনি provideValidationFeedback এন্ডপয়েন্টে একটি অনুরোধ পাঠাতে পারেন।

এটি 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

dpvConfirmation এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।

ঠিকানার প্রতিক্রিয়া subpremise এর মান সহ missingComponentType ক্ষেত্র রয়েছে।

ঠিকানা উদাহরণ নিশ্চিত করুন

একটি ঠিকানা গ্রহণ করুন

আপনি একটি ঠিকানা গ্রহণ করেন যখন রায় উচ্চ মাত্রার আত্মবিশ্বাস প্রদান করে যে ঠিকানাটি বিতরণযোগ্য এবং ডাউনস্ট্রীম প্রক্রিয়ায় গ্রাহকের মিথস্ক্রিয়া ছাড়াই ব্যবহার করা যেতে পারে।

সংকেত গ্রহণ করুন

ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।

1. বৈধকরণ গ্রানুলারিটি

PREMISE বা তার চেয়ে ভালোর একটি validationGranularity গ্রহণযোগ্য, কিন্তু কিছু ক্ষেত্রে, ROUTE এখনও একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে।

2. অন্যান্য সংকেত

একটি উচ্চ মানের ঠিকানার জন্য একটি রায় নিম্নলিখিত প্রদান করা উচিত:

  • কোনও প্রতিস্থাপিত ডেটা নেই । এই ক্ষেত্রে, hasReplacedComponents: FALSE
  • কোন অনুমানকৃত উপাদান নেই । এই ক্ষেত্রে, hasInferredComponents: FALSE

3. মার্কিন ঠিকানা সংকেত

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

dpvConfirmation Y

dpvConfirmation এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।

ঠিকানা উদাহরণ গ্রহণ করুন

,

এই নথিটি ঠিকানা যাচাইকরণ 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.

সঠিক যুক্তি আপনার পরিস্থিতির উপর নির্ভর করে - আরো বিস্তারিত জানার জন্য বাস্তবায়ন নির্দেশিকা দেখুন। আপনি আমাদের এই যুক্তির ওপেন সোর্স বাস্তবায়ন ব্যবহার করতে পারেন, যা এক্সটেন্ডেড কম্পোনেন্ট লাইব্রেরিতে রয়েছে।

ওয়ার্কফ্লো ওভারভিউ

নীচের টেবিলটি আপনার সিস্টেমের জন্য দুটি কর্মের সংক্ষিপ্ত বিবরণ দেয়:

  1. ফিক্স, নিশ্চিতকরণ, আচরণ গ্রহণের উপর ভিত্তি করে ব্যবহার করার জন্য কর্মপ্রবাহ
  2. প্রতিক্রিয়া থেকে পরীক্ষা করার জন্য প্রথম সংকেত । এখানে বর্ণিত সংকেতগুলি verdict সম্পত্তি থেকে আসে এবং এটি পরীক্ষা করার জন্য একমাত্র সংকেত নয় , তবে ঠিকানার গুণমানের একটি প্রাথমিক নির্দেশক প্রদান করে৷ প্রতিটি আচরণের ধরন এই নথির একটি বিভাগের সাথে মিলে যায় যাতে আরও সংকেত বর্ণনা করা হয় যা আপনাকে তদন্ত করতে হবে।
আপনার সিস্টেম আচরণ
ঠিকানা ঠিক করুন

verdict প্রতিক্রিয়া নির্দেশ করে গুরুত্বপূর্ণ অনুপস্থিত তথ্য যা প্রদান করা উচিত। ঠিকানা যাচাইকরণ API দ্বারা প্রত্যাবর্তিত ঠিকানা বিতরণযোগ্য মানের নাও হতে পারে।

কর্মপ্রবাহ

  1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
  2. ঠিকানা সমস্যা ঠিক করতে গ্রাহককে অনুরোধ করুন।
  3. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
  4. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
  5. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত যে কোনো একটি প্রযোজ্য:

ঠিকানা নিশ্চিত করুন

verdict প্রতিক্রিয়া একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে, কিন্তু মূল ইনপুটে পরিবর্তন করেছে: অনুমানকারী ডেটা যা হয় বানান সংশোধন করা হয়েছে, বা ডেটা যা নিশ্চিত করা যেতে পারে।

কর্মপ্রবাহ

  1. সংশোধন প্রয়োজন:
    1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
    2. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
    3. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
    4. ঠিকানা দিয়ে এগিয়ে যান।
  2. কোন সংশোধনের প্রয়োজন নেই:
    1. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
    2. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত সব প্রযোজ্য:

  • validationGranularity এর মধ্যে ROUTE বা আরও ভাল আছে। গ্রানুলিটি মান দেখুন।
  • addressComplete সম্পূর্ণ true
  • hasInferredComponents ক্ষেত্রটি true বা hasReplacedComponents ক্ষেত্রটি true
ঠিকানা গ্রহণ করুন

ঠিকানা যাচাইকরণ API প্রতিক্রিয়া একটি চমৎকার মানের ঠিকানা নির্দেশ করে।

কর্মপ্রবাহ

ফেরত ঠিকানা দিয়ে এগিয়ে যান.

রায় সংকেত

নিম্নলিখিত সব প্রযোজ্য:

  • validationGranularity এর মধ্যে PREMISE বা আরও ভালো থাকে। গ্রানুলিটি মান দেখুন।
  • addressComplete সম্পূর্ণ true
  • কোন অনুমান বা প্রতিস্থাপিত উপাদান.

বাস্তবায়ন নির্দেশিকা

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

নির্দেশনা বিস্তারিত
ঝুঁকির স্তর

সংশোধনের জন্য অনুরোধ করা এবং প্রবেশ করা ঠিকানাটি গ্রহণ করার মধ্যে ভারসাম্য বজায় রাখার সময় আপনার পরিস্থিতির জন্য সহনশীলতার মাত্রা বিবেচনা করুন।

ঠিকানা যাচাইকরণ API বিভিন্ন ধরণের সংকেত প্রদান করে যা আপনি আপনার বৈধকরণ প্রক্রিয়াকে অপ্টিমাইজ করতে আপনার ঝুঁকির স্তরের সাথে অন্তর্ভুক্ত করতে পারেন।

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

ঠিকানা গ্রহণ করুন

গ্রাহক প্রম্পটে সাড়া না দিলে আপনার সিস্টেমকে আসল এন্ট্রি গ্রহণ করার অনুমতি দেওয়া একটি ভাল অভ্যাস।

এই ক্ষেত্রে, গ্রাহক সিস্টেমে নেই এমন একটি ঠিকানা লিখতে পারে, যেমন নতুন নির্মাণের জন্য।

মতামত প্রদান

আপনি যখন একটি ঠিকানা যাচাইকরণের অনুরোধ পুনরায় ইস্যু করেন, আপনি provideValidationFeedback এন্ডপয়েন্টে একটি অনুরোধ পাঠাতে পারেন।

এটি 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

dpvConfirmation এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।

ঠিকানার প্রতিক্রিয়া subpremise এর মান সহ missingComponentType ক্ষেত্র রয়েছে।

ঠিকানা উদাহরণ নিশ্চিত করুন

একটি ঠিকানা গ্রহণ করুন

আপনি একটি ঠিকানা গ্রহণ করেন যখন রায় উচ্চ মাত্রার আত্মবিশ্বাস প্রদান করে যে ঠিকানাটি বিতরণযোগ্য এবং ডাউনস্ট্রীম প্রক্রিয়ায় গ্রাহকের মিথস্ক্রিয়া ছাড়াই ব্যবহার করা যেতে পারে।

সংকেত গ্রহণ করুন

ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।

1. বৈধকরণ গ্রানুলারিটি

PREMISE বা তার চেয়ে ভালোর একটি validationGranularity গ্রহণযোগ্য, কিন্তু কিছু ক্ষেত্রে, ROUTE এখনও একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে।

2. অন্যান্য সংকেত

একটি উচ্চ মানের ঠিকানার জন্য একটি রায় নিম্নলিখিত প্রদান করা উচিত:

  • কোনও প্রতিস্থাপিত ডেটা নেই । এই ক্ষেত্রে, hasReplacedComponents: FALSE
  • কোন অনুমানকৃত উপাদান নেই । এই ক্ষেত্রে, hasInferredComponents: FALSE

3. মার্কিন ঠিকানা সংকেত

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

dpvConfirmation Y

dpvConfirmation এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।

ঠিকানা উদাহরণ গ্রহণ করুন

,

এই নথিটি ঠিকানা যাচাইকরণ 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.

সঠিক যুক্তি আপনার পরিস্থিতির উপর নির্ভর করে - আরো বিস্তারিত জানার জন্য বাস্তবায়ন নির্দেশিকা দেখুন। আপনি আমাদের এই যুক্তির ওপেন সোর্স বাস্তবায়ন ব্যবহার করতে পারেন, যা এক্সটেন্ডেড কম্পোনেন্ট লাইব্রেরিতে রয়েছে।

ওয়ার্কফ্লো ওভারভিউ

নীচের টেবিলটি আপনার সিস্টেমের জন্য দুটি কর্মের সংক্ষিপ্ত বিবরণ দেয়:

  1. ফিক্স, নিশ্চিতকরণ, আচরণ গ্রহণের উপর ভিত্তি করে ব্যবহার করার জন্য কর্মপ্রবাহ
  2. প্রতিক্রিয়া থেকে পরীক্ষা করার জন্য প্রথম সংকেত । এখানে বর্ণিত সংকেতগুলি verdict সম্পত্তি থেকে আসে এবং এটি পরীক্ষা করার জন্য একমাত্র সংকেত নয় , তবে ঠিকানার গুণমানের একটি প্রাথমিক নির্দেশক প্রদান করে৷ প্রতিটি আচরণের ধরন এই নথির একটি বিভাগের সাথে মিলে যায় যাতে আরও সংকেত বর্ণনা করা হয় যা আপনাকে তদন্ত করতে হবে।
আপনার সিস্টেম আচরণ
ঠিকানা ঠিক করুন

verdict প্রতিক্রিয়া নির্দেশ করে গুরুত্বপূর্ণ অনুপস্থিত তথ্য যা প্রদান করা উচিত। ঠিকানা যাচাইকরণ API দ্বারা প্রত্যাবর্তিত ঠিকানা বিতরণযোগ্য মানের নাও হতে পারে।

কর্মপ্রবাহ

  1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
  2. ঠিকানা সমস্যা ঠিক করতে গ্রাহককে অনুরোধ করুন।
  3. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
  4. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
  5. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত যে কোনো একটি প্রযোজ্য:

ঠিকানা নিশ্চিত করুন

verdict প্রতিক্রিয়া একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে, কিন্তু মূল ইনপুটে পরিবর্তন করেছে: অনুমানকারী ডেটা যা হয় বানান সংশোধন করা হয়েছে, বা ডেটা যা নিশ্চিত করা যেতে পারে।

কর্মপ্রবাহ

  1. সংশোধন প্রয়োজন:
    1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
    2. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
    3. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
    4. ঠিকানা দিয়ে এগিয়ে যান।
  2. কোন সংশোধনের প্রয়োজন নেই:
    1. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
    2. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত সব প্রযোজ্য:

  • validationGranularity এর মধ্যে ROUTE বা আরও ভাল আছে। গ্রানুলিটি মান দেখুন।
  • addressComplete সম্পূর্ণ true
  • hasInferredComponents ক্ষেত্রটি true বা hasReplacedComponents ক্ষেত্রটি true
ঠিকানা গ্রহণ করুন

ঠিকানা যাচাইকরণ API প্রতিক্রিয়া একটি চমৎকার মানের ঠিকানা নির্দেশ করে।

কর্মপ্রবাহ

ফেরত ঠিকানা দিয়ে এগিয়ে যান.

রায় সংকেত

নিম্নলিখিত সব প্রযোজ্য:

  • validationGranularity এর মধ্যে PREMISE বা আরও ভালো থাকে। গ্রানুলিটি মান দেখুন।
  • addressComplete সম্পূর্ণ true
  • কোন অনুমান বা প্রতিস্থাপিত উপাদান.

বাস্তবায়ন নির্দেশিকা

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

নির্দেশনা বিস্তারিত
ঝুঁকির স্তর

সংশোধনের জন্য অনুরোধ করা এবং প্রবেশ করা ঠিকানাটি গ্রহণ করার মধ্যে ভারসাম্য বজায় রাখার সময় আপনার পরিস্থিতির জন্য সহনশীলতার মাত্রা বিবেচনা করুন।

ঠিকানা যাচাইকরণ API বিভিন্ন ধরণের সংকেত প্রদান করে যা আপনি আপনার বৈধকরণ প্রক্রিয়াকে অপ্টিমাইজ করতে আপনার ঝুঁকির স্তরের সাথে অন্তর্ভুক্ত করতে পারেন।

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

ঠিকানা গ্রহণ করুন

গ্রাহক প্রম্পটে সাড়া না দিলে আপনার সিস্টেমকে আসল এন্ট্রি গ্রহণ করার অনুমতি দেওয়া একটি ভাল অভ্যাস।

এই ক্ষেত্রে, গ্রাহক সিস্টেমে নেই এমন একটি ঠিকানা লিখতে পারে, যেমন নতুন নির্মাণের জন্য।

মতামত প্রদান

আপনি যখন একটি ঠিকানা যাচাইকরণের অনুরোধ পুনরায় ইস্যু করেন, আপনি provideValidationFeedback এন্ডপয়েন্টে একটি অনুরোধ পাঠাতে পারেন।

এটি 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

dpvConfirmation এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।

ঠিকানার প্রতিক্রিয়া subpremise এর মান সহ missingComponentType ক্ষেত্র রয়েছে।

ঠিকানা উদাহরণ নিশ্চিত করুন

একটি ঠিকানা গ্রহণ করুন

আপনি একটি ঠিকানা গ্রহণ করেন যখন রায় উচ্চ মাত্রার আত্মবিশ্বাস প্রদান করে যে ঠিকানাটি বিতরণযোগ্য এবং ডাউনস্ট্রীম প্রক্রিয়ায় গ্রাহকের মিথস্ক্রিয়া ছাড়াই ব্যবহার করা যেতে পারে।

সংকেত গ্রহণ করুন

ঠিকানা যাচাইকরণ API আপনাকে একটি ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত প্রদান করে।

1. বৈধকরণ গ্রানুলারিটি

PREMISE বা তার চেয়ে ভালোর একটি validationGranularity গ্রহণযোগ্য, কিন্তু কিছু ক্ষেত্রে, ROUTE এখনও একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে।

2. অন্যান্য সংকেত

একটি উচ্চ মানের ঠিকানার জন্য একটি রায় নিম্নলিখিত প্রদান করা উচিত:

  • কোনও প্রতিস্থাপিত ডেটা নেই । এই ক্ষেত্রে, hasReplacedComponents: FALSE
  • কোন অনুমানকৃত উপাদান নেই । এই ক্ষেত্রে, hasInferredComponents: FALSE

3. মার্কিন ঠিকানা সংকেত

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

dpvConfirmation Y

dpvConfirmation এর বিস্তারিত জানার জন্য, হ্যান্ডেল মার্কিন যুক্তরাষ্ট্রের ঠিকানা দেখুন।

ঠিকানা উদাহরণ গ্রহণ করুন

,

এই নথিটি ঠিকানা যাচাইকরণ 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.

সঠিক যুক্তি আপনার পরিস্থিতির উপর নির্ভর করে - আরো বিস্তারিত জানার জন্য বাস্তবায়ন নির্দেশিকা দেখুন। আপনি আমাদের এই যুক্তির ওপেন সোর্স বাস্তবায়ন ব্যবহার করতে পারেন, যা এক্সটেন্ডেড কম্পোনেন্ট লাইব্রেরিতে রয়েছে।

ওয়ার্কফ্লো ওভারভিউ

নীচের টেবিলটি আপনার সিস্টেমের জন্য দুটি কর্মের সংক্ষিপ্ত বিবরণ দেয়:

  1. ফিক্স, নিশ্চিতকরণ, আচরণ গ্রহণের উপর ভিত্তি করে ব্যবহার করার জন্য কর্মপ্রবাহ
  2. প্রতিক্রিয়া থেকে পরীক্ষা করার জন্য প্রথম সংকেত । এখানে বর্ণিত সংকেতগুলি verdict সম্পত্তি থেকে আসে এবং এটি পরীক্ষা করার জন্য একমাত্র সংকেত নয় , তবে ঠিকানার গুণমানের একটি প্রাথমিক নির্দেশক প্রদান করে৷ প্রতিটি আচরণের ধরন এই নথির একটি বিভাগের সাথে মিলে যায় যাতে আরও সংকেত বর্ণনা করা হয় যা আপনাকে তদন্ত করতে হবে।
আপনার সিস্টেম আচরণ
ঠিকানা ঠিক করুন

verdict প্রতিক্রিয়া নির্দেশ করে গুরুত্বপূর্ণ অনুপস্থিত তথ্য যা প্রদান করা উচিত। ঠিকানা যাচাইকরণ API দ্বারা প্রত্যাবর্তিত ঠিকানা বিতরণযোগ্য মানের নাও হতে পারে।

কর্মপ্রবাহ

  1. প্রয়োজনে ঠিকানা উপাদান তদন্ত.
  2. ঠিকানা সমস্যা ঠিক করতে গ্রাহককে অনুরোধ করুন।
  3. আপডেট করা ঠিকানার জন্য বৈধতার অনুরোধ করুন।
  4. (ঐচ্ছিক) API এর জন্য প্রতিক্রিয়ার শেষ পয়েন্টে একটি অনুরোধ পাঠান। আপডেট করা ঠিকানা হ্যান্ডেল দেখুন।
  5. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত যে কোনো একটি প্রযোজ্য:

নিশ্চিত করুন

verdict থেকে প্রাপ্ত প্রতিক্রিয়া একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে, তবে মূল ইনপুটটিতে পরিবর্তন করেছে: অনুমান করা ডেটা যা হয় বানান সংশোধন করা হয়, বা ডেটা যা নিশ্চিত করা যায়।

কর্মপ্রবাহ

  1. সংশোধন প্রয়োজন:
    1. প্রয়োজনে ঠিকানা উপাদানগুলি তদন্ত করুন।
    2. আপডেট হওয়া ঠিকানার জন্য বৈধতার অনুরোধ করুন।
    3. (Al চ্ছিক) এপিআইয়ের জন্য প্রতিক্রিয়া শেষ পয়েন্টে একটি অনুরোধ প্রেরণ করুন। আপডেট হওয়া ঠিকানাগুলি হ্যান্ডেল দেখুন।
    4. ঠিকানা দিয়ে এগিয়ে যান।
  2. কোনও সংশোধন প্রয়োজন:
    1. (Al চ্ছিক) এপিআইয়ের জন্য প্রতিক্রিয়া শেষ পয়েন্টে একটি অনুরোধ প্রেরণ করুন। আপডেট হওয়া ঠিকানাগুলি হ্যান্ডেল দেখুন।
    2. ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত সমস্ত আবেদন:

  • validationGranularity ROUTE বা আরও ভাল থাকে। গ্রানুলারিটির মান দেখুন।
  • addressComplete true
  • hasInferredComponents ক্ষেত্রটি true বা hasReplacedComponents ক্ষেত্রটি true
ঠিকানা গ্রহণ করুন

ঠিকানা বৈধতা এপিআই প্রতিক্রিয়া একটি দুর্দান্ত মানের ঠিকানা নির্দেশ করে।

কর্মপ্রবাহ

ফেরত ঠিকানা দিয়ে এগিয়ে যান।

রায় সংকেত

নিম্নলিখিত সমস্ত আবেদন:

  • validationGranularity গ্রানুলারিটিতে PREMISE বা আরও ভাল থাকে। গ্রানুলারিটির মান দেখুন।
  • addressComplete true
  • কোনও অনুমিত বা প্রতিস্থাপন উপাদান নেই

বাস্তবায়ন নির্দেশিকা

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

নির্দেশনা বিস্তারিত
ঝুঁকির স্তর

সংশোধনের জন্য অনুরোধ জানানো এবং প্রবেশের মতো ঠিকানা গ্রহণের মধ্যে ভারসাম্য বজায় রাখার সময় আপনার পরিস্থিতির জন্য সহনশীলতার স্তরটি বিবেচনা করুন।

ঠিকানা বৈধতা এপিআই বিভিন্ন সংকেত দেয় যা আপনি আপনার বৈধতা প্রক্রিয়াটি অনুকূল করতে আপনার ঝুঁকি স্তরের সাথে অন্তর্ভুক্ত করতে পারেন।

উদাহরণস্বরূপ, যদি কোনও ঠিকানায় একটি অসমর্থিত রাস্তার নম্বর থাকে তবে আপনি এখনও এটি গ্রহণ করতে পারেন। অন্যদিকে, যদি আপনার ব্যবসায়ের অপারেশনের জন্য আরও বেশি ঠিকানার নির্ভুলতা প্রয়োজন হয় তবে আপনি আপনার ব্যবহারকারীর অনুরোধ করতে পারেন। উদাহরণস্বরূপ যা উভয় বিভাগে পড়তে পারে এমন একটি উদাহরণের জন্য, গ্রহণযোগ্য ঠিকানায় অ -মার্কিন অসমর্থিত রাস্তার নম্বর দেখুন - উদাহরণগুলি

ঠিকানা গ্রহণ করুন

গ্রাহক প্রম্পটগুলিতে সাড়া না দিলে আপনার সিস্টেমকে মূল এন্ট্রি গ্রহণের অনুমতি দেওয়ার জন্য এটি একটি ভাল অনুশীলন।

এই ক্ষেত্রে, গ্রাহক সিস্টেমে না এমন কোনও ঠিকানা প্রবেশ করতে পারেন, যেমন নতুন নির্মাণের জন্য।

মতামত প্রদান

আপনি যখন কোনও ঠিকানা বৈধকরণের অনুরোধটি পুনরায় ইস্যু করেন, আপনি provideValidationFeedback এন্ডপয়েন্টে একটি অনুরোধও প্রেরণ করতে পারেন।

এটি গুগলকে জানতে দেয় যে আপনি কীভাবে চূড়ান্ত প্রতিক্রিয়াটি শেষ পর্যন্ত পরিচালনা করেছেন। আপডেট হওয়া ঠিকানাগুলি হ্যান্ডেল দেখুন।

একটি ঠিকানা ঠিক করুন

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

সংকেত ঠিক করুন

ঠিকানা বৈধতা এপিআই আপনাকে কোনও ঠিকানা ঠিক করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত সরবরাহ করে।

1। বৈধতা গ্রানুলারিটি এবং অনুপস্থিত উপাদানগুলি

এই দুটি সংকেত সমস্যাযুক্ত ঠিকানার সেরা ইঙ্গিত সরবরাহ করে:

  • যখনই validationGranularity ক্ষেত্রটি OTHER হয়, ত্রুটিটি কোথায় ঘটেছে এবং কীভাবে এটি ঠিক করা যায় সে সম্পর্কে আরও জানতে আপনার সিস্টেমে ঠিকানা উপাদান সংকেতগুলি তদন্ত করা উচিত।
  • যখনই পোস্ট-প্রসেসড address অবজেক্টটি অনুপস্থিত missingComponentTypes ক্ষেত্রটি ফেরত দেয়, আপনার সিস্টেমে সেই উপাদানটির জন্য পরীক্ষা করা উচিত। অনুপস্থিত উপাদানগুলি একটি ঠিকানা অসম্পূর্ণ এবং বিতরণযোগ্যও সরবরাহ করে।

2। অন্যান্য সংকেত

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

সন্দেহজনক উপাদান যখন কোনও উপাদানটির জন্য নিশ্চিতকরণ স্তরের এনামটি UNCOMFIRMED_AND_SUSPICIOUS হয়, সম্ভবত উপাদানটি ভুল।
অমীমাংসিত উপাদান একটি অমীমাংসিত টোকেন ইনপুটটির একটি অংশ যা কোনও ঠিকানার বৈধ অংশ হিসাবে স্বীকৃত নয়।

3। মার্কিন ঠিকানা সংকেত

কেবলমাত্র আমাদের ঠিকানাগুলিতে প্রযোজ্য কিছু ক্ষেত্রগুলি একটি দরকারী সংকেত সরবরাহ করে যে ঠিকানাটি বিতরণযোগ্য নয় এবং এটি স্থির করা উচিত। যে ঠিকানার জন্য ফিক্সিং প্রয়োজন, আপনার নিম্নলিখিতগুলি দেখতে হবে:

dpvConfirmation হয় N , D , বা খালি।

dpvConfirmation সম্পর্কিত বিশদগুলির জন্য, মার্কিন যুক্তরাষ্ট্রের ঠিকানাগুলি হ্যান্ডেল করুন

ঠিকানা উদাহরণ ঠিক করুন

একটি ঠিকানা নিশ্চিত করুন

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

গ্রাহককে সঠিক প্রম্পটিং সরবরাহ করতে, আপনার যুক্তি পরিষেবাটি দ্বারা পতাকাঙ্কিত উপাদানগুলি সনাক্ত করতে পারে যে কোন ক্রিয়াকলাপ বা পতাকাটি উপাদানটিতে প্রয়োগ করা হয়েছে, যেমন inferred , replaced বা spellCorrected নির্ধারণ করতে। রেফারেন্সে অ্যাড্রেসকম্পোনেন্ট দেখুন।

সংকেত নিশ্চিত করুন

ঠিকানা বৈধতা এপিআই আপনাকে কোনও ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত সরবরাহ করে।

1। বৈধতা গ্রানুলারিটি

ROUTE বা আরও ভাল এর একটি validationGranularity গ্রহণযোগ্য, তবে প্রিমিজ বা সাবপ্রাইজটি বিতরণযোগ্যতার একটি শক্তিশালী সংকেত সরবরাহ করে।

2। অন্যান্য সংকেত

গ্রাহকের সাথে ঠিকানা প্রবেশের বিষয়টি নিশ্চিত করার সিদ্ধান্ত নেওয়ার সময়, রায়টি কোন উপাদানগুলি তদন্ত করতে হবে তা নির্ধারণের জন্য নিম্নলিখিতগুলিও সরবরাহ করে:

অনুমানিত ডেটা যখন hasInferredComponents ক্ষেত্রটি true হয়, আপনি জানেন যে এপিআই এটি অন্য ঠিকানা উপাদানগুলি থেকে সংগ্রহ করা তথ্যগুলিতে পূরণ করেছে।
প্রতিস্থাপন ডেটা যখন hasReplacedComponents ক্ষেত্রটি true হয়, এপিআই প্রতিস্থাপন করা ডেটাগুলির সাথে প্রবেশ করা ডেটা এটি ঠিকানাটি বৈধ করার জন্য বলে মনে করা হয়।

3। মার্কিন ঠিকানা সংকেত

কেবলমাত্র আমাদের কাছে প্রযোজ্য কিছু ক্ষেত্রগুলি নির্দেশ করে যে আপনার যুক্তিটি গ্রাহকের সাথে বিশদটি নিশ্চিত করা উচিত। নিম্নলিখিত উভয়ই আবেদন:

dpvConfirmation S

dpvConfirmation সম্পর্কিত বিশদগুলির জন্য, মার্কিন যুক্তরাষ্ট্রের ঠিকানাগুলি হ্যান্ডেল করুন

ঠিকানা প্রতিক্রিয়া subpremise মান সহ missingComponentType ক্ষেত্র রয়েছে।

ঠিকানা উদাহরণ নিশ্চিত করুন

একটি ঠিকানা গ্রহণ করুন

রায় যখন রায়টি উচ্চ মাত্রার আত্মবিশ্বাস সরবরাহ করে যে ঠিকানাটি বিতরণযোগ্য এবং ডাউন স্ট্রিম প্রক্রিয়াতে আরও গ্রাহকের মিথস্ক্রিয়া ছাড়াই ব্যবহার করা যেতে পারে তখন আপনি একটি ঠিকানা গ্রহণ করেন।

সংকেত গ্রহণ করুন

ঠিকানা বৈধতা এপিআই আপনাকে কোনও ঠিকানা নিশ্চিত করা উচিত কিনা তা জানাতে বেশ কয়েকটি সংকেত সরবরাহ করে।

1। বৈধতা গ্রানুলারিটি

PREMISE বা আরও ভাল একটি validationGranularity গ্রহণযোগ্য, তবে কিছু ক্ষেত্রে ROUTE এখনও একটি বিতরণযোগ্য ঠিকানা নির্দেশ করে।

2। অন্যান্য সংকেত

একটি উচ্চমানের ঠিকানার জন্য একটি রায় নিম্নলিখিতগুলি সরবরাহ করা উচিত:

  • কোনও প্রতিস্থাপন ডেটা নেই । এই ক্ষেত্রে, hasReplacedComponents: FALSE
  • কোনও অনুমানযুক্ত উপাদান নেই । এই ক্ষেত্রে, hasInferredComponents: FALSE

3। মার্কিন ঠিকানা সংকেত

কেবলমাত্র আমাদের কাছে প্রযোজ্য কিছু ক্ষেত্রগুলি একটি উচ্চমানের ঠিকানা নির্দেশ করে যা সরবরাহ করা যেতে পারে। একটি গ্রহণযোগ্য মার্কিন ঠিকানার জন্য, আপনার নিম্নলিখিতগুলি দেখতে হবে:

dpvConfirmation Y

dpvConfirmation সম্পর্কিত বিশদগুলির জন্য, মার্কিন যুক্তরাষ্ট্রের ঠিকানাগুলি হ্যান্ডেল করুন

ঠিকানা উদাহরণ গ্রহণ করুন