JSON-RPCおよびその他のRPCのようなAPIには、多くの場合、本体で定義されたメソッドを持つ単一のURIしかありません。 エディターが警告を出さず、APIコンソールが適切なオーバーロードされた結果を返すように、これらのリソースに対して複数のアクションを定義できると便利です。
apiary.ioに移動します。
@rodriguiseこの問題に関する情報はどこにありますか? 私も同じ考えを持っています。RPCのようなAPIをサポートするのは素晴らしい機能でしょう。
@rodriguise私もこの機能に非常に興味がありますが、この問題についてどこで学ぶことができるか教えていただけますか?
@adammbalogh @SvyatoslavVasilievユースケースについてもう少し説明していただけますか?
@pksunkara確かに。
JSON-RPC 2.0仕様に従って設計されたAPIがあります。例:
POST 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には、メソッドの名前が本文に含まれているメソッドグループの「method」パラメータのURLが1つだけあります。
現在のブループリントの実現では、パス中心の言語構造のため、そのようなAPIを記述することはできません。
こんにちは@pksunkara 、これについて何かニュースはありますか?
私は養蜂場の代わりに他のレンダリングツール(たとえばaglio)を使用しようとしましたが、養蜂場とは対照的に、それらはドキュメントを正しく表現していました。 ただし、これらのツールは、属性などの一部の機能を個別のセクションとしてレンダリングすることをサポートしていません。
私の問題を解決するのを手伝っていただければ幸いです。
@SvyatoslavVasilievさん、これを正しく読んだ場合、JSON RPCのサポートはhttps://github.com/apiaryio/api-blueprint/issues/289に分類されますが、技術的にはプロトコルは引き続きHTTPです。
リソースとアクション定義をURIとHTTPメソッドから切り離すことは、この場合にも役立つはずです。
これは理にかなっていますか? 詳細については、#289を参照してください
こんにちは@zdne 、
#289を理解しようとしましたが、完全には理解できません。
私のAPIはトランスポートとしてJSON本文を含むHTTPを使用していますが、URLは1つだけで、HTTPPOSTのみを使用しています。 「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"
}
}
HTTPPOSTと呼ばれる両方のメソッドhttp://myservice.com/rpcapi
これまでのところ、JSON-RPC APIを文書化する最新の機能的な方法は見つかりませんでした(テストの生成にも使用できます)。 私の望みはAPIブループリントでしたが、実際にはサポートされていないようです。 誰かがこれのAPIブループリントの将来の計画を知っているか、これをサポートする別の構造/ツールの提案がありますか?
@Dynom私はいくつかのアドバイスを与えることができます。
APIブループリントのAglioレンダリングを試すことができます。属性セクションはレンダリングされませんが、ドキュメントの構造は正しく表示されます。
もう1つのツールはAPIDocです。現在テスト中ですが、適切と思われます。
ありがとう@SvyatoslavVasilievインラインドキュメントソリューションを使用したくありません