Api-blueprint: دعم التحميل الزائد URI لـ JSON-RPC

الانتقال إلى apiary.io.

rodriguise أين يمكنني العثور على معلومات حول هذه المشكلة؟ لدي نفس الفكرة ، سيكون من الجيد دعم واجهات برمجة التطبيقات التي تشبه RPC.

rodriguise أنا مهتم جدًا بهذه الوظيفة أيضًا ، هل يمكنك أن تقول أين يمكنني التعرف على هذه المشكلة؟

adammbaloghSvyatoslavVasiliev يمكن يا رفاق يصف حالة استخدامك أكثر قليلا؟

تضمين التغريدة
لدي واجهة برمجة تطبيقات مصممة وفقًا لمواصفات JSON-RPC 2.0 ، على سبيل المثال:

انشر http://somehost.com/rpc_api

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "entity.get",
  "params": {
    "filter": {
      "filters": [
        {
          "field": "name",
          "operator": "eq",
          "value": "Bob"
        },
        {
          "field": "age",
          "operator": "eq",
          "value": 25
        }
      ],
      "condition": "and"
    }
  }
}

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

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

مرحبًا SvyatoslavVasiliev ، لذا إذا قرأت هذا بشكل صحيح ، فإن دعم JSON RPC يقع تحت https://github.com/apiaryio/api-blueprint/issues/289 وإن كان البروتوكول من الناحية الفنية لا يزال HTTP.

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

هل هذا منطقي؟ الرجاء مراجعة # 289 للحصول على تفاصيل إضافية

مرحبًا zdne ،
حاولت أن أفهم # 289 ، لكني لا أستطيع أن أفهمها بالكامل.
تستخدم واجهة برمجة التطبيقات (API) الخاصة بي HTTP مع نص JSON كوسيلة نقل ، ولكنها تحتوي على عنوان URL واحد فقط وتستخدم HTTP POST فقط. جميع المعلومات حول الموارد والطريقة الواردة في معلمة "الطريقة" في الجسم.
على سبيل المثال ، احصل على الكيان:
{ "jsonrpc": "2.0", "id": 1, "method": "entity.get", "params": { "filter": { "filters": [ { "field": "name", "operator": "eq", "value": "Bob" }, { "field": "age", "operator": "eq", "value": 25 } ], "condition": "and" } } }

حذف الكيان:
{ "jsonrpc": "2.0", "id": 1, "method": "entity.delete", "params": { "id": "123" } }

تسمى كلتا الطريقتين بـ HTTP POST http://myservice.com/rpcapi

حتى الآن لم أجد طريقة حديثة وعملية لتوثيق واجهة برمجة تطبيقات JSON-RPC (والتي يمكنني استخدامها أيضًا لإنشاء الاختبارات). كان أملي هو مخطط API ولكن يبدو أنه غير مدعوم حقًا. هل يعرف أي شخص الخطط المستقبلية لـ API Blueprint لهذا أو لديه اقتراح لهيكل / أداة مختلفة تدعم ذلك؟

Dynom يمكنني تقديم نصائح للزوجين.
يمكنك تجربة عرض Aglio لمخطط api ، فهو لا يعرض قسم السمات ، ولكنه يعرض بنية المستند بشكل صحيح.
أداة أخرى هي API Doc ، أنا أختبرها في اللحظة الحالية ويبدو أنها مناسبة.

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