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