Api-blueprint: Поддержка перегрузки URI для JSON-RPC

Созданный на 27 апр. 2014  ·  11Комментарии  ·  Источник: apiaryio/api-blueprint

JSON-RPC и другие API-интерфейсы, подобные RPC, часто имеют только один URI с методом, определенным в теле. Было бы неплохо иметь возможность определять несколько действий с этими ресурсами, чтобы редактор не выдавал предупреждений, а консоль API возвращала соответствующий перегруженный результат.

Question

Все 11 Комментарий

Переходим на apiary.io.

@rodriguise Где я могу найти информацию по этой проблеме? У меня такая же мысль, было бы неплохо поддерживать RPC-подобные API.

@rodriguise Меня тоже очень интересует эта функция, не могли бы вы сказать, где я могу узнать об этой проблеме?

@adammbalogh @SvyatoslavVasiliev , ребята, вы можете

@pksunkara конечно.
У меня есть API, разработанный в соответствии со спецификацией 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"
    }
  }
}

Такой API имеет только один URL-адрес для группы методов, где имена методов содержатся в теле, в параметре «метод».
Текущая реализация Blueprint не позволяет описывать такой API из-за структуры языка, ориентированной на пути.

Привет, @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. Вся информация о ресурсе и методе содержится в параметре "method" в теле.
Например, получить сущность:
{ "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, но похоже, что он не поддерживается. Кто-нибудь знает будущие планы API Blueprint этого или есть предложение для другой структуры / инструмента, который поддерживает это?

@Dynom Я могу дать пару советов.
Вы можете попробовать Aglio render для api blueprint, он не отображает раздел атрибутов, но правильно отображает структуру документа.
Еще один инструмент - API Doc , сейчас тестирую и он мне подходит.

Спасибо @SvyatoslavVasiliev. Я не хочу использовать встроенные решения для документации, а API Doc объявляет, что это для служб RESTful, поэтому я не уверен, что мы можем ожидать многого от этого в долгосрочной перспективе.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

mootpointer picture mootpointer  ·  4Комментарии

robbinjanssen picture robbinjanssen  ·  6Комментарии

zatziky picture zatziky  ·  4Комментарии

fh-thudson picture fh-thudson  ·  3Комментарии

pete001 picture pete001  ·  6Комментарии