it-swarm.asia

تصميم URI لعلاقات كثير إلى كثير: المشورة اللازمة

أنا عالق في تصميم URIs لعلاقة كثير إلى كثير بين المستخدمين والموارد الأخرى. على وجه التحديد ، أواجه صعوبة في التنبؤ بعواقب الأساليب المختلفة.

نظرًا لأنواع الموارد user و widget (user تمثل مستخدمًا مسجلاً)) ، يتمتع المستخدمون المصادقون (الذين قاموا بتسجيل الدخول) بحق الوصول للكتابة إلى جميع عناصر واجهة التعامل ويمكن للضيوف الوصول للقراءة. تحتوي علاقة عنصر واجهة المستخدم أيضًا على بيانات (على سبيل المثال ، عدد التعديلات) التي يجب أن تكون قابلة للقراءة أيضًا (وبالتالي عنونة ) من قبل الضيوف (و ، - كما يشير Lèse أدناه ، للمستخدمين الآخرين). تستخدم الأمثلة أعداد صحيحة لمعرفات فريدة من أجل الوضوح.

يمكن للضيوف عرض القطعة رقم 12 على

/widgets/12

ما هي الآثار المترتبة على مختلف URIs المحتملة للمستخدم المصادق عليه # 34 لقراءة/كتابة القطعة رقم 12 ، واختياريا للضيف لقراءة البيانات العلائقية بين الاثنين؟ (لا تقلق بشأن تقديم إجابة شاملة ، ستكون أي ملاحظات مع أو ضد خيارات محددة ذات قيمة كبيرة أيضًا).

/widgets/12

(المستخدم ضمنيًا استنادًا إلى المصادقة ، لا توجد وسيلة للضيف لتحديد علاقة عنصر واجهة المستخدم)

/users/34/widgets/12

(كلا جانبي العلاقة التسلسل الهرمي الصريح والضمني بين الموارد)

/users/34/widgets/12 and /widgets/12/users/34

(نفسه ، بدون التسلسل الهرمي)

/user-widget/34,12

(العلاقة كمورد ، صريحة ولكن ربما أكثر مما يحتاج المستخدم إلى معرفته)


يسعدني تقديم المزيد من التفاصيل أو إضافة اقتراحات URI للأشخاص الآخرين. فقط قم بالتعليق إذا كنت تريد مني إضافة أي شيء.

4
Ian Mackinnon

يجب أن يكون عنوان URL للوصول إلى عنصر واجهة المستخدم هو نفسه بالنسبة للجميع. يعتمد التحكم في ما يجب إظهاره أو القدرات التي يمتلكها المستخدم على معرف المستخدم ، والذي يمكن الاحتفاظ به ، على سبيل المثال ، في متغير جلسة.

لذلك عند تحميل عنصر واجهة المستخدم/12 ، يجب أن تتحقق صفحة الويب الخاصة بك من هوية المستخدم في متغير الجلسة ، وأنظر ما هي أذوناتها ، ثم تقوم بتنسيق الصفحة بناءً على تلك الأذونات.

3
milesmeow

كيف يسمح النموذج /widgets/12 للضيوف بقراءة الأدوات - أو السماح للمستخدمين بقراءة عناصر واجهة المستخدم للمستخدمين الآخرين؟ أم أنك تخطط لتنفيذ أشكال متعددة؟

شخصيا ، أود أن أفعل شيئا مثل:

/widget/id:12/user:665
/widget/12/665
/widget/12?user=665

في النهاية ، لا يهم عنوان URL ما لم يكن هذا هو الأمر الذي يريد المستخدمون الوصول إليه مباشرةً. إذا كان مجرد موقع لبرنامج نصي قابل للتضمين أو موجز بيانات أو أي نوع آخر من الخدمة ، فيمكنك استخدام أي عنوان URL تريده ، وفي هذه الحالة سأذهب مع شيء مثل:

/widget?id=12&uid=665

تحرير:
أفضل فقط تقديم الأداة المصغّرة ضمن /widget لأن هذا هو المورد. أفترض أن علاقة عنصر واجهة المستخدم - ضمنية بنوع عنصر واجهة المستخدم. لذا فإن إضافة users إلى التسلسل الهرمي للمسار أمر غير ضروري.

الآن ، إذا كنت تريد أن يتمكن الأشخاص من تصفح الأدوات المصغرة لمستخدم معين ، فسيكون النموذج /users/34/widgets/12 هو الأفضل.

2
Lèse majesté

إذا كان الأمر يتعلق بالمصادقة ، فلن أتمكن من تمريرها عبر عنوان URL على الإطلاق. ما الذي يمنعني من تغيير معرف المستخدم في عنوان URL والحصول على أذونات ليس من المفترض أن أقوم بها؟

0
GSto