هل يعد اختيارًا سيئًا لاستهلاك REST API من النهاية الخلفية أيضًا؟

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

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

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

So the question is, are there some reasons which make this a bad idea?

4
يشار إلى هذا عادةً باسم بنية الخدمات الموجهة .
وأضاف المؤلف Philipp, مصدر

5 إجابة

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

إذا كنت تتحكم في التصميم والمكونات الخلفية ، باستخدام واجهة برمجة تطبيقات RESTful - خاصة في التنسيق العام ، على سبيل المثال ، خدمة HTTP و المشفرة باستخدام JSON - غير كفء بشكل ملحوظ مقارنة بالبدائل الأخرى (مثل الارتباط المباشر للمكتبات ، تخزين البروتوكول ، التوفير ، أنواع مختلفة من ESB ، وآليات RPC الأخرى ، ...) التي لا تمر عبر إجراء تسلسل إلى نص أو خدمة أو إلغاء تسلسل من دورة نصية لكل مكالمة API. REST هي أيضا أفضل بشكل دلالي كآلية تفاعل على طول السلاح ، بالنظر إلى أن بعض التركيبات (مثل المعاملات متعددة الخطوات ، التدفق ، الأشياء الثنائية الكبيرة ، رفع الاستثناءات ، التسليم المضمون ، ...) هي أكثر بساطة ، نظيفة ، أو يتم التعامل معها مباشرة أشكال أخرى من التفاعل.

بعض الأسباب التي قد لا تزال ترغب في استخدام الواجهة الخلفية لـ RESTful: البساطة والاتساق (كل عميل ، محلي أو بعيد ، يمر عبر واجهة برمجة تطبيقات واحدة فقط) ، ووقت الوصول إلى السوق (على سبيل المثال لا يحتاج إلى تعلم نمط واجهة برمجة تطبيقات/تفاعل آخر). تفترض هذه أنك تقوم بتعريض قاعدة البيانات الخاصة بك ، بشكل مباشر نسبياً ، من خلال RESTful API. إذا كان الاستخدام الدقيق للمكونات تحت سيطرتك ، فربما لا يكون REST هو الخيار الأفضل (سواء للثراء أو الكفاءة).

5
وأضاف
هذه إجابة رائعة. إذا كنت تحتفظ بأجهزة تحكم REST الخاصة بك رقيقة ومسؤولة فقط عن "طلب التقسيم ، استدعاء نموذج فئة الأعمال lib ، إرجاع النتيجة" ، فمن المعقول تماماً استدعاء هذه المكتبة مباشرة. فقط حذار المنطق غير المتصل HTTP في وحدات التحكم الخاصة بك.
وأضاف المؤلف RubberDuck, مصدر
شكرا لإجابتك! ونعم ، أحد الشواغل الرئيسية هو عدم الكفاءة وأفكر في طريقة لإلغاء طبقة الوصول من تنفيذ واجهة برمجة التطبيقات ، حتى أتمكن من الوصول إليها بطريقة REST ولكن مباشرة من الشفرة ، وبالتالي القضاء على جميع النفقات العامة بسبب HTTP
وأضاف المؤلف Henrik, مصدر

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

فكر في الأمر ، حيث إن قوة واجهة برمجة التطبيقات (API) هي عادةً العدد الكبير والمتنوعة من منفذي "العميل" الذين يمكنهم استهلاكها. يجب أن لا يكون ذلك مختلفًا في حالتك.

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

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

3
وأضاف

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

عن طريق استخراج I/O من api ونقلها إلى اعتراضية ، يمكنك استخدام prehandler/posthandler لتسليم الاتصالات واستخدام مؤشر ترابط واحد لمعالجة في الحلقة.

تدفق I/O من بوابة api إلى مثيل التطبيق لأدوات الاستجابة هو تدفق constan واحد وليس مكسورة.

اطلع على التجريد api وتسلسل api لمزيد من المعلومات ( http://www.slideshare.net/bobdobbes/API-التجريد-المعهد-تسلسل )

0
وأضاف
إنه البحث العلمي المفتوح المصدر الذي غالباً ما يطلب مني تقديمه في SpringOne و Apple و Amazon و Mashery و Paypal وغيرها من المؤسسات. ما الذي يفترض أن أضعه كإنتمائي؟ الذات :)
وأضاف المؤلف Ian Storm Taylor, مصدر
أفهم ما تقوله تمامًا. الناس عبوس على تعزيز الذات/التبشير الملائكي. لكنك لا تستطيع في الوقت نفسه أن تسحقها دون سحق النقاش العلمي للأفكار الجديدة. عليك أن تكون حذرا في كلا الاتجاهين ... إنه موقف صعب لأنني سمعتك.
وأضاف المؤلف Ian Storm Taylor, مصدر
"يميل المجتمع هنا إلى التصويت من أجل الترويج الذاتي العلني ووضع علامة عليه كرسائل غير مرغوب فيها. قم بإرسال إجابات جيدة وذات صلة ، وإذا كان بعض (ولكن ليس كل) يحدث عن منتجك أو موقعك الإلكتروني ، فلا بأس بهذا. لكن يجب عليك الكشف عن الانتماء في إجاباتك ". ( مركز المساعدة> نموذجنا> كيف لا تكون مرسلي البريد غير المرغوب )
وأضاف المؤلف gnat, مصدر
وأضاف المؤلف gnat, مصدر

يتميز استخدام واجهة برمجة تطبيقات REST من الواجهة الخلفية بميزتين: ليس عليك تطوير واجهة برمجة تطبيقات أخرى وتوثيقها ، وليس لديك سوى مجموعة واحدة من الأخطاء ، وليس اثنتين.

هناك اعتراضان محتملان: من الممكن أن يكون لديك الواجهة الخلفية أشياء لا تتناسب مع واجهة برمجة التطبيقات الحالية (نظرًا لأنها قد تنظر إلى البيانات من الاتجاه المعاكس كما تفعل واجهة برمجة التطبيقات في الواجهة الأمامية). وقد تكون هناك مشكلات في الأداء: إذا كانت الواجهة الخلفية تستخدم قاعدة البيانات عشرة أضعاف ما تفعله الواجهة الأمامية ، وهذا هو الأداء الحرج ، فإنك لا تريد أبسط واجهة برمجة تطبيقات ، ولكن الأسرع.

لذلك تحقق من كيفية استخدام الواجهة الخلفية لقاعدة البيانات والبت فيها. إذا كانت الواجهة الخلفية لديك سعيدة بوظيفة REST API ولا توجد مشكلات في الأداء ، فاستخدم واجهة برمجة تطبيقات REST.

0
وأضاف
حتى لو كانت الخلفية سعيدة. هل يستحق فضح جميع الوصول إلى ديسيبل إلى Falacies للحوسبة الموزعة؟
وأضاف المؤلف glacier, مصدر

A lot of good answers and comments. To me, it seems microservice oriented. The challenge is that there is slight overhead inserting a layer between your data access and the backend code that churns on that data. Overhead in terms of development time & cycles, and overhead in terms of code performance. But the upsides are that your application components are more loosely coupled so you can extend/change the code with less complexity. If everything that accesses the data does so through the API, then any changes you need to make to the underlying data model if you make the API handle seamlessly then you are done.

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

0
وأضاف