واجهة برمجة تطبيقات GraphQL مقابل واجهة برمجة تطبيقات REST

الاختلافات الرئيسية بين REST و GraphQL ومتى يكون من الأفضل استخدام أحدهما مقابل الآخر

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

الباقي مفهوم

REST هو معيار معماري واقعي ولكنه في الواقع ليس له مواصفات وأطنان من التعريفات غير الرسمية تمتلك GraphQL امتدادًاتخصيصمسودة ، وهيلغة الاستعلامبدلاً من الهندسة المعمارية ، مع مجموعة محددة جيدًا من الأدوات المبنية حولها (ونظام بيئي مزدهر).

بينما تم بناء REST فوق بنية موجودة ، والتي في السيناريوهات الأكثر شيوعًا هيHTTPمن ناحية أخرى ، تبني GraphQL مجموعتها الخاصة من الاصطلاحات. والتي يمكن أن تكون نقطة ميزة أم لا ، لأن فوائد RESTمجاناعن طريق التخزين المؤقت على طبقة HTTP.

نقطة نهاية واحدة

لدى GraphQL نقطة نهاية واحدة فقط ، حيث ترسل جميع استفساراتك. باستخدام نهج REST ، يمكنك إنشاء نقاط نهاية متعددة واستخدام HTTPأفعاللتمييز إجراءات القراءة (GET) وكتابة الإجراءات (POSTوPUTوDELETE). لا تستخدم GraphQL أفعال HTTP لتحديد نوع الطلب.

مصممة لتناسب احتياجاتك

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

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

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

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

طريقة رائعة لتصور هذا هو مثال على ملفنقطة نهاية البيتزا(أنا إيطالي ، مثال بيتزا مثالي).

إذا اتصلتGET /pizza/margherita، ستحصل على بيتزا مارغريتا. إذا اتصلتGET /pizza/napoli، ستحصل على بيتزا نابولي.

إذا كان لديك 30 نكهة مختلفة ، فسيكون لديك 30 نقطة نهاية (إلا إذا قمت بتمرير اسم البيتزا كمعامل إلىGET /pizza، على سبيل المثال)

لكن ربما تريد نوعًا معينًا من البيتزا ، لكن بدون مكون واحد لا تحبه. من السهل أن تطلب من النادل ، ولكن من الصعب التعبير عن نقطة نهاية REST.

تتيح لك نقطة نهاية GraphQL الاتصال/pizza، وتسأل عن مكونات محددة ، لبناء البيتزا المثالية التي تريدها.

تجعل GraphQL من السهل مراقبة استخدام الحقول

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

تتيح GraphQL تتبع الحقول التي يستخدمها العملاء.

الوصول إلى موارد البيانات المتداخلة

تسمح GraphQL بتوليد مكالمات شبكة أقل بكثير.

لنفعل مثالاً: تحتاج إلى الوصول إلى أسماء أصدقاء شخص ما. إذا كشف REST API الخاص بك عن ملف/personنقطة النهاية ، التي تُرجع كائنًا بشخصًا مع قائمة من الأصدقاء ، عادةً ما تحصل أولاً على معلومات الشخص عن طريق العملGET /person/1، والتي تحتوي على قائمة معرف لأصدقائها.

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

مع GraphQL ، تحتاج إلى طلب واحد فقط يسأل عن أسماء أصدقاء الشخص.

أنواع

تعتمد واجهة برمجة تطبيقات REST على JSON والتي لا يمكنها توفير التحكم في النوع.تمتلك GraphQL نظام كتابة.

أيهما أفضل؟

تتساءل المؤسسات في جميع أنحاء العالم عن خيارات تقنية API الخاصة بهم وتحاول معرفة ما إذا كان الترحيل من REST إلى GraphQL هو الأفضل لاحتياجاتهم.

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

كما هو الحال مع لغات البرمجة ، لا يوجد فائز واحد ، كل هذا يتوقف على احتياجاتك.

أيضًا ، هناك نقطة أريد توضيحها: يمكنك استخدام كليهما.

يمكنك مزج ومطابقة REST و GraphQL وفقًا لاحتياجاتك ، وأحيانًا يكون هذا هو أفضل شيء تفعله.


المزيد من دروس الرسم البياني: