ব্যাকএন্ড আইডিগুলি কি কোনও REST এপিআইতে প্রকাশ্যে হওয়া উচিত?


14

এই লোকটি যা বলে তার উপর ভিত্তি করে: http://toddfredrich.com/ids-in-rest-api.html

ধরে নেওয়া যাক তিনি এপিআই সংস্থানগুলি সনাক্ত করতে ইউইউডি ব্যবহার করার বিষয়ে সঠিক। তারপরে আমি এটিকে বাস্তবায়নের চেষ্টা করে সমস্যায় পড়ি, এটি হ'ল:

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

(ক্লায়েন্ট এবং সার্ভারের মধ্যে, পাঠানো এবং ডিটিও নেওয়া হয়, ডেটা বেস সত্তা নয়))

এখন সমস্যাটি হ'ল এটি কার্যকর idনয় কারণ আমি এটি আর ব্যবহার করি না। ক্লায়েন্টটি অনুরোধগুলি করে uidতাই আমি কেন 2 আইডি হ্যান্ডেল করতে বিরক্ত করব? তারপরে আমরা শুরুতে একই ইস্যুতে ফিরে আসি। আমি যদি ইউইউডিটিকে প্রাথমিক কী ( _id) হিসাবে সেট করে রাখি তবে আমি ব্যাকএন্ড আইডিটি জনসাধারণের কাছে প্রকাশ করছি।

তার পাশাপাশি, কার্যক্ষমতা বিষয় রয়েছে। আমি পড়েছি যে অবজেক্টআইডি দ্বারা সূচকগুলি ইউআইডি থেকে অনেক বেশি দক্ষ efficient

উত্তর:


7

আমি জনসাধারণের কাছে ব্যাকএন্ড আইডি প্রকাশ করছি

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

দক্ষতার বিষয়

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


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

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

1
আপনার প্রশ্নের উত্তর হিসাবে " আপনার সত্তাগুলি যখন কোনও অনুরোধের মাধ্যমে ফেরত আসে তখন আপনাকে কী কী তা চিহ্নিত করতে হবে? ", প্রতি সেশনের প্রক্সি আইডি। " সর্বোত্তম সুরক্ষা হ'ল সূচক, অপ্রত্যক্ষ রেফারেন্স ম্যাপ, বা অন্য যে পরোক্ষ পদ্ধতি যাচাই করা সহজ ব্যবহার করে ব্যবহারকারীদের কাছে সরাসরি অবজেক্টের রেফারেন্স প্রকাশ করা এড়ানো "
পিটার টেলর

5

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

আপনি যদি getUserAccountByID (12345) করতে পারেন তবে কেবলমাত্র একজনকে getUserAccountByID (12346) চেষ্টা করার জন্য বলছে। অন্যান্য সুরক্ষা ব্যবস্থার কারণে এটি কাজ করবে না, এমনকি অ্যাকাউন্টে তথ্য জিজ্ঞাসা করে কোম্পানিকে সামাজিক হ্যাক করার চেষ্টাও করবেন না এবং চেষ্টা করুন না: যদি আপনি ডিবিএকে কল না করেন এবং একটি সপ্তাহের জন্য 2 সপ্তাহ অপেক্ষা করতে ইচ্ছুক না হন reponse;)

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

এটি নিরর্থক নয়। দুটি ক্ষেত্র বিভিন্ন উদ্দেশ্যে পরিবেশন করে।


0

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

  • পান [...] / 1
  • পান [...] / 2

আইডি ব্যবহার করার সময় এটি খুব সহজ, আপনি যদি এর পরিবর্তে ইউআইডি ব্যবহার করেন তবে এটি স্ক্র্যাপারের জন্য একটি কম বিকল্প।

আপনার অ্যাপ্লিকেশনটির ডাটাবেসের উদাহরণটিতে আইডিটিকে অভ্যন্তরীণ কিছু হিসাবে দেখা যেতে পারে। এই বাক্যে তিনটি গুরুত্বপূর্ণ শব্দ রয়েছে:

  • অ্যাপ্লিকেশন: যেহেতু এটি আপনার মডেল এটি সম্ভবত আপনার টেবিলগুলি কেবলমাত্র সেই অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হবে
  • ডাটাবেস: একাধিক অ্যাপ্লিকেশন যদি এটি একই ডাটাবেসের বিরুদ্ধে ব্যবহার করে তবে আপনি ঠিকঠাক হয়ে যাবেন
  • দৃষ্টান্ত (ডাটাবেসের): আপনার যদি বিতরণ সিস্টেম থাকে, আইডি একে অপরের সাথে বিরোধী হয় এবং আপনার ডাটাবেসের উদাহরণটি ব্যবহার করে না এমন অন্য কোনও সিস্টেম / অ্যাপ্লিকেশনটির জন্য এগুলি অর্থহীন হবে। ইউআইইডি হ'ল সেই নির্দিষ্ট ক্ষেত্রে সমাধান।

ব্যক্তিগত পছন্দ অনুসারে: আমি একটি সাধারণ আইডি এবং একটি অনন্য ব্যবসায় আইডি পছন্দ করি (মেল, লগইন, ...)। সুতরাং যদি আমাকে ডেটা এক্সচেঞ্জ করতে হয় তবে আমি ব্যবসায়ের আইডি ব্যবহার করব, কারণ টার্গেট সিস্টেমটি ইউআইডি হ্যান্ডেল করতে পারে না, তবে তিনি খুব সম্ভবত (কখনই বলবেন না ...) হ্যান্ডেল একটি অনন্য ব্যবসায়ের কী ব্যবহার করবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.