أمثلة على أفضل واجهات برمجة تطبيقات ويب الصابون/RPC؟ ولماذا تحبهم؟ وما الخطأ معهم؟ [مغلق
https://stackoverflow.com/questions/409338
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
في شركتي ، بدأنا في التفرع في واجهات برمجة تطبيقات الويب للوصول إلى بياناتنا وتحديثها ؛ في البداية للشركاء ولكن من المحتمل بعد ذلك للجمهور في المستقبل. في الوقت الحالي ، فإن الطريقة التي ستبدو بها واجهة برمجة التطبيقات (مثل الصابون والراحة و RPC) مفتوحة تمامًا ولم نتخذ أي قرارات بعد ، لذلك أنا مهتم بكلا الأمثلة على واجهات برمجة التطبيقات على شبكة الإنترنت يعتقدون أنها جيدة ، ولماذا تفكر الذي - التي.
ما يهمني هو آراء الأشخاص الذين يستخدمون لغات مختلفة (من المحتمل أن نقدم واجهة برمجة التطبيقات للأشخاص الذين يستخدمون عدد من المنصات ، لا سيما بما في ذلك .NET و Java و ActionScript و JavaScript) حول واجهات برمجة التطبيقات على شبكة الإنترنت التي تعتقد أنها جيدة أمثلة ، وأن لديك تجارب جيدة معها.
بعض النقاط التي أود تغطيتها:
هل تفضل خدمات نوع SOAP أو REST/RPC Style؟ أظن أن الأشخاص الذين يحملون دعم المنصة (على سبيل المثال .NET ، JAVA) يفضلون الصابون والأشخاص الذين يستخدمون اللغات دون دعم منصة سيفضلون الآخرين ، لكنني أود التحقق من صحة هذا الافتراض.
هل تهتم بما إذا كانت واجهة برمجة التطبيقات (API) مريحة بالفعل أو ما إذا كانت عبارة عن نمط RPC قديم HTTP GET/POST؟ إذا كان الأمر كذلك ، فلماذا تهتم؟ هل من المهم أن تصف واجهة برمجة التطبيقات نفسها بشكل صحيح (أي لا تدعي أنها مريحة إذا كان نمط RPC) أكثر من ما إذا كانت في الواقع واحدة من الاثنين؟
نحن بحاجة إلى التحقق من من يستخدم الخدمة. لقد كنت أبحث في مصادقة Amazon S3 التي تستخدم معرفًا عامًا ورمزًا خاصًا يستخدم لتجزئة معلمات الطلب في رمز التحقق (وهذا يشبه أيضًا Flickr). هل استخدمت هذا النوع من المصادقة من قبل ، وكيف حصلت عليه؟ هل هناك أي خوارزميات تجزئة تجدها مشكلة (أي غير مدعومة من خلال منصتك)؟ هل تفضل إرسال التجزئة في رأس HTTP أو في URI؟
كيف يجب التعامل مع الإصدار؟ هل من الجيد أن يكون لديك ملف
/v1/اكتب الدليل الفرعي بحيث يمكن إضافة الإصدارات المستقبلية جنبًا إلى جنب ، أو هل ستفعل شيئًا مختلفًا مثل الإصدار في حمولة الطلب أو الاستعلام؟ كم من الوقت تتوقع إصدارًا من واجهة برمجة التطبيقات التي قمت ببنائها مقابل دعمها (أي إذا تم تقديم V2 ، فما هو توقعك حول عمر V1).
أيضا ، أي آراء أخرى ونقاط لتغطية ستكون مفيدة.
إنني أظل غامضًا عن عمد على النوع الفعلي من واجهة برمجة التطبيقات التي ننفذها ، حيث إنني أبحث عن إرشادات عامة فيما يتعلق بما يعتقد الناس أنه آلات واجهات برمجة التطبيقات وآليات التنفيذ الجيدة ، لذلك سيكون هذا المنشور وإجاباته مفيدة لمزيد من الناس فى المستقبل.
ملاحظة: لقد بحثت ولا يمكنني العثور على سؤال عام حول هذا - يبدو أنهم جميعًا محددين لنوع معين من واجهة برمجة التطبيقات - ولكن إذا كان ذلك مكررًا ، فيرجى إخبارنا بذلك. وأيضًا إذا كان يجب أن يكون ويكي المجتمع (أعتقد أن الناس يجب أن يحصلوا على الفضل للحصول على إجابات ، لذا لم أقم بذلك) ، فيرجى إخبارنا وسأغيرها.
المحلول
ها هو رأيي.
على الرغم من أن قادمًا من وجهة نظر Java ، إلا أنني أفضل الراحة. مظروف الصابون مع مساحات أسماء متعددة وهيكله المعقد هو رجس. يحاول حل المشكلات الخيالية في الغالب ، ولا يحل أي شيء بكفاءة. الشيء الوحيد في الصابون الذي وجدته مفيدًا هو أنه يحتوي على معايير للترخيص والأخطاء. من ناحية أخرى ، يمكن حل كلاهما بشكل أسهل بكثير من خلال تضمين أربع سمات قياسية في عنصر XML الجذر - اسم المستخدم ، كلمة المرور ، ErrorCode ، Errordescription.
وصف وثيقة API الجيدة هي في الواقع كل ما يهم. الفرق بين الراحة والصابون في الإطار الناضج هو في الغالب في بضعة أسطر من التكوين.
للصابون ، أرسل التجزئة كجزء من أمان الصابون ؛ للراحة ، أود أن أحزم كل شيء في الحمولة النافعة وتجنب رؤوس HTTP للمصادقة. ليس لدي أسباب ذاتية فقط ، حيث اضطررت إلى القتال مع الأطر التي لا تعرض رؤوس HTTP بسهولة.
تفضيلي الشخصي هو وجود URIs مختلف لإصدارات بروتوكول مختلفة. في تجربتي ، يمنحك هذا مزيد من المرونة في الإصدارات الأحدث ، والعملاء القدامى الذين يتصلون بالإصدارات غير المدعومة من البروتوكول تتوقف عن العمل على الفور ولأسباب واضحة. أيضًا ، في بعض الأحيان ، يمكنك تعيين الإصدار القديم من التطبيق إلى Old URI ، لتجنب وجود رمز دعم قديم في إصدار خادم جديد.
بالنسبة إلى المدة التي تدعم فيها الإصدار القديم من البروتوكول ... بشكل مثالي ، طالما أن لديك عملاء يستخدمونه. هذا عمل أكثر من القرار الفني. يجب أن تدعم إصدار بروتوكول سابق واحد على الأقل. عادة ما يكون من مصلحتك دفع العملاء نحو إصدار جديد لخفض تكاليف الدعم القديمة ؛ من جانب العملاء ، يجب أن يعني الإصدار الجديد ميزات جديدة ، وبروتوكول أفضل ، ونوع من الحوافز التجارية الإضافية (إذا كانت الميزات الجديدة وحدها ليست كافية).
نصائح أخرى
قد تكون مهتمًا بعرض Joshua Bloch التقديمي "كيفية تصميم واجهة برمجة تطبيقات جيدة ولماذا يهم". Joshua Bloch مؤلف كتاب "Java الفعال" ومهندس برمجيات رئيسي ورئيس Java Architect في Google.
الملخص: http://portal.acm.org/citation.cfm؟id=1176622
يتم تغطية الإصدار للراحة باستخدام رؤوس نوع المحتوى بشكل جيد هنا: http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
نهج RPC هو أيضا خيار جيد. إنه يقلل من النفقات العامة ، وتسهل مشاريع مثل ICE و Google Protocol Protocol و Apache Thrift أسهل في تطوير خدمات RPC أسهل.
إذا لم يكن عليك تقديم واجهة برمجة تطبيقات على الويب ، فيمكن أن يكون RPC أيضًا خيارًا تريد استكشافه.
سأرى ما تفعله أمازون - http://aws.amazon.com/ - فإن اللاعبين يكسبون المال من هذه الأشياء ، سيتعلمون دروسًا أكثر من أي شخص آخر.
كانت API الأخرى التي سأبحث عنها - salesforce.com و microsofts CRM API كانت مثيرة للاهتمام إلى حد ما. Twitter لديه معركة صلابة API أيضا.
IMHO ، كل هذا يتوقف على نوع التطبيقات التي تقدمها. إذا كنت تقوم بعمل معاملات مهمة ، فمن المؤكد أن تذهب مع الصابون (WS "Death Star" كما يسمونها). ولكن إذا كنت تقدم تطبيقات اجتماعية ، فانتقل مع REST ، لأنه أبسط ومناسب أفضل للقرصنة العامة.
من السهل فهم REST ، إذا تم القيام به بشكل صحيح ، (النماذج HTTP) ، مباشرة (موجهة للموارد) ويمكن تحليلها بواسطة كل لغة برمجة (XML).
إذا لم تتمكن من اتخاذ قرار في النهاية ، فيمكنك تنفيذها جميعًا. في هذه الحالات ، من المفيد أن ننظر إلى كيفية قيام الآخرين بذلك. أوصيك بمفتوح قاعدة بيانات XML الأصلية يوجد الذي - التي يقدم الأنواع الثلاثة من الواجهات أنت تتصرف.
