موقع ئي باي مثل واجهة API لبوابة الويب

Question

لقد قمنا بتطوير بوابة ويب B2B لـ Graphics Job Work والتي تشبه Camera Ready Art (www.camerareadyart.com).إنه موجه للأشخاص الذين يرغبون في تحويل الصورة النقطية إلى رسومات متجهة وتصميم الشعار ومعالجة الصور العامة مثل تلوين صور B/W إلى ألوان، وما إلى ذلك.

نريد إضافة تسهيلات حتى يتمكن الأشخاص (عملاؤنا) من استخدام مجموعة من واجهات برمجة التطبيقات (API) التي نقدمها لنشر أعمالهم من موقعهم مباشرة دون الحاجة إلى زيارة موقعنا حرفيًا لنشر أعمالهم.

لم أفعل شيئًا كهذا حتى الآن، لذا ليس لدي أي أفكار حول كيفية تنفيذ شيء كهذا.أريد أيضًا أن أعرف كيف يمكننا تنفيذ الأمان بحيث لا يتمكن سوى الأشخاص المصرح لهم من نشر أعمالهم؟

هل يمكن لأي شخص أن يعطيني أفكارًا حول كيف يمكننا القيام بشيء كهذا.

Answer 1

يغطي هذا السؤال مساحة كبيرة جدًا وأشك في أن أي إجابة واحدة يمكن أن تغطي الأمور بالتفصيل.ما يمكنني فعله هو تقديم بعض نقاط البداية بناءً على الأخطاء التي ارتكبتها.

البناء على واجهة برمجة التطبيقات (API) الخاصة بك
لا تقم بإضافة ميزات API إلى نظام موجود.سيؤدي القيام بذلك إلى:

• يؤدي إلى حمل اختبار إضافي (سيتعين عليك اختبار كل من تطبيقك وواجهة برمجة التطبيقات بشكل مستقل)
• يؤدي إلى زيادة في تكاليف الصيانة الشاملة
• يؤدي إلى واجهة برمجة تطبيقات ذات جودة أقل مما تريد تقديمه

يجب أن يكون هدفك العام هو إنشاء واجهة برمجة التطبيقات أولاً ثم إنشاء تطبيقك فوق واجهة برمجة التطبيقات الخاصة بك.القيام بذلك له الفوائد التالية:

• يتم إجراء اختبار واجهة برمجة التطبيقات (API) بطبيعتها أثناء اختبار تطبيقك
• لن "تنسى" إضافة أي من طرق واجهة برمجة التطبيقات المطلوبة

سيتم فصل تطبيقك ومنطق التطبيق الخاص بك (واجهة برمجة التطبيقات) منطقيًا - سيكون هناك فصل واضح بينهما من حيث ما يفعله كل جانب من المعادلة وما هو المسؤول عنه.وهذا سوف يساعد في توجيه التنمية.سيسمح لك هذا أيضًا بوضع التطبيق وواجهة برمجة التطبيقات (API) بسهولة شديدة على أجهزة مختلفة عند الحاجة إلى ذلك.

يعد استخدام واجهة برمجة التطبيقات (API) الخاصة بك نقطة مهمة جدًا.سيكون تصميم واجهة برمجة التطبيقات (API) الخاصة بك في البداية دون المستوى الأمثل، وفقط من خلال استخدامها بنفسك، ستتمكن من جعلها تقدم للأشخاص الميزات المطلوبة بالفعل بطريقة فعالة.

سينتهي بك الأمر مع نظام يبدو تقريبًا كما يلي:

-------------                          -------------
|           |                          |           |
| Your APP  | <= HTTP communication => | Your API  |
|           |                          |           |
-------------                          -------------

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

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

أنا شخصيًا أفضل ربط عناوين URL بالفئات والأساليب بالطرق التالية:

• تعيين الفئات إلى أدلة المستوى الأعلى
• تعيين الأساليب إلى الدلائل الفرعية لأدلة المستوى الأعلى

مثال:
عنوان URL لواجهة برمجة التطبيقات الخاصة بك هو https://api.camerareadyart.com.
انت تملك image كائن مع toColour() و toBlackAndWhite() طُرق.

قد يتم تعيين هذا إلى:

https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/

وبالمثل بالنسبة لتحويل الصورة النقطية إلى المتجهات:

https://api.camerareadyart.com/bitmap/toVector/

تصميم الردود
عندما يحصل شخص ما على بيانات من أحد عناوين URL الخاصة بك أو يرسلها إليها، ماذا يحدث؟كيف يتم التعامل مع الأخطاء وكيف يتم التعامل مع الاستثناءات؟ما هو الشكل الذي تتخذه الردود؟

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

على سبيل المثال، إذا تم قبول طلب وارد وتمت معالجته ولكن حدث خطأ داخليًا، فسوف أقوم بإصدار استجابة الحالة 500.وبالمثل، إذا كانت طريقة API معينة تتطلب مصادقة لم يتم توفيرها، فقد أقوم بإصدار 403.إن الاستفادة من ميزات HTTP الموجودة تمنعك من الاضطرار إلى إعادة اختراع أشياء معينة.

استخدم الجوانب الحالية لـ HTTP
بالإضافة إلى استخدام رموز حالة HTTP بشكل معقول، تأكد من البحث عن طريقة HTTP فقط للقيام بشيء ما قبل طرح الحل الخاص بك.

هل تريد من المستخدم تحديد ما إذا كان تنسيق الاستجابة يجب أن يكون بتنسيق XML أو JSON؟استخدم رأس قبول HTTP.

هل تريد إعادة توجيه العميل إلى عنوان URL مختلف للحصول على نتيجة الطلب؟استخدم رأس موقع HTTP.

هناك العديد من ميزات HTTP التي تتعامل بالفعل مع العديد من الأشياء التي قد ترغب في القيام بها.استخدمهم!

حماية
هناك مشكلتان عامتان يجب معالجتهما هنا:مصادقة المستخدم، وتحديد الإجراءات التي يمكن لمستخدم معين القيام بها.

حماية:المصادقة
سيحتاج المستخدم إلى تحديد هويته في طلبه.

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

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

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

يتيح لك ذلك فصل اسم المستخدم وكلمة المرور بشكل منطقي عن الوصول إلى واجهة برمجة التطبيقات.يمكن للمستخدم تغيير اسم المستخدم و/أو كلمة المرور لتطبيقك بقدر ما يريد دون قطع وصوله إلى واجهة برمجة التطبيقات.

يمكن للمستخدم أيضًا أن يكون لديه رموز API متعددة، لكل منها مستويات مختلفة من الوصول، مما يسمح للمستخدم بإعطاء رمز API المميز لخدمة جهة خارجية بأمان.

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

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

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

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

Answer 2

وتحتاج الواضح أن خدمات ويب الخلفية الخاصة بك تصميم والعمل. ومع ذلك، كل ميزات إضافية (الأمن، اختناق، أوث الإدارية الرئيسية، بوابة المشترك، وحدة تفاعلية في محاولة واجهات برمجة التطبيقات، الخ) هي مجموعة موحدة إلى حد ما من الميزات التي ربما لا ينبغي أن تطور نفسك.

وهناك حلول إدارة API التجارية في السوق. أعمل لWSO2، التي لديها 100٪ مفتوح المصدر (اباتشي رخصة) مدير WSO2 API، والتي يمكن تنزيلها مجانا <لأ href = "http://wso2.com/api-management/try-it/" يختلط = "نوفولو"> هنا أو استخدام كإصدار سحابة استضافتها في WSO2 API سحابة .