問題タブ [json-rpc]

私のJSON-RPCクライアント（dojo JSON-RPCを使用するブラウザー）は、 myserver.com / 12345（Python 2.5、SimpleJSONRPCServer）上のJSON-RPCサーバーにJSON-RPC要求（dojo.callRemote）を送信します。

次に、サーバーはヘッダー「OPTIONS / HTTP / 1.1」を含むHTTPリクエストを取得しますが、これはデフォルトでは処理できないため、このリクエストのカスタムハンドラーを作成しました。

ブラウザからのリクエストヘッダーには次のように書かれています。

そして、私が送信する応答は次のようになります。

しかし、ブラウザで次のエラーが発生します。

エラー： http：//myserver.com： 12345 status：0を読み込めません

JSONサービスがネットから到達可能であることを確認しました。

ここで問題となるのは、ブラウザ（Firefoxなど）は、応答の聞き手が言うことを何を期待しているのかということです。それとも問題は他の場所にありますか？

JSON-RPCWebサービスを実装します。このための仕様が必要です。これまでのところ、実際の仕様として呼び出すことができるリソースは1つしか見つかりませんでした。

• JSON-RPC 1.0 http://json-rpc.org/wiki/specification
• JSON-RPC 2.0の提案：http：//groups.google.com/group/json-rpc/web/json-rpc-2-0（なぜGoogleグループにあるのですか？）

ただし、DojoのようなJavaScriptフレームワークがJSON-RPCSMDを積極的に使用していることを確認しました

• サービスマッピングの説明の提案

ただし、JSONスキーマの仕様が必要ですが、参照として誤ったURLにリダイレクトされます。これまでのところ、私は次のことを発見しました。

• https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-02

そしてそれはまだドラフトです...

誰かが私にいくつかの実際の仕様を指摘できますか...少なくとも公式に更新されたものはありますか？少なくともDojoのようなフレームワークでは、JSON-RPC1.0をそのまま実装するだけでは不十分なように見えるためです。それとも私は間違っていますか？

質問：

• JSON-RPC 1.0仕様の実装は、最新のクライアントのほとんどにJSON-RPCサービスを提供するのに十分であり、JSON-RPC 1.0を超える機能（SMD、スキーマ、2.0）を実際にサポートするクライアントがいくつあるか（あるとしても） ？

  JSON-RPC 1.0は公式の仕様を持っているだけのように見えるので（ドラフトではありません）

• SMDを実装する必要がある場合、または誰かがJsonスキーマとサービスマッピングの説明の公式の最新の仕様を指すことが推奨されている場合、または私が見つけたリンクは本当に「仕様」ですか？

• JSON-RPC 2.0、SMD、JSON-Schemaドラフトは、それらを実装するのに十分安定していますか？

注：既存のJSON-RPCサービスの実装を提案しないでください。

誰か？

編集： JSON-RPCを使用している人はいますか？

チームに共通しているが、異なるネットワークから呼び出される特定のタスクを実行するために、単純なRPCサーバーを作成しました。サーバーは次のようになります（簡潔にするためのエラー処理は含まれていません）。

これは非常に簡単です。サーバーはクライアントからJSONRPCリクエストを受信し、メソッドを探し、パラメーターを渡してメソッドを呼び出します。メソッド自体は、JSONRPC応答を返すメソッドです。あまり馴染みのない人にとっては、JSONRPCはおおよそ次のようになります。

私が持っているRPCサーバーは、現在の目的を非常にうまく果たしています（ご想像のとおり、私のタスクは非常に単純です）。ただし、タスクの複雑さが増すにつれて、メソッドを追加し続ける必要があります。

def method3(...)メインファイルを開いてさらに別のファイルを追加し、2週間後に追加するなどしたくありませんdef method4(...)。コードの成長が速すぎて、メンテナンスがますます難しくなります。

だから、私の質問は、サーバーにメソッドを登録できるアーキテクチャをどのように作成できるかということです。ボーナスは、メソッドごとに1つのファイルを保持する別のフォルダーを用意して、それらを簡単に共有および保守できるようにすることです。この「アーキテクチャ」により、Twistedの理解に関係なく、他の誰かにいくつかのメソッドの保守を延期することもできます。

新しいメソッドが登録されるたびにサーバーを再起動する必要があるかどうかは気にしませんが、私も持っていない場合は明らかなプラスになります:)。

ありがとう。

最近のプロジェクトでは、PHP スクリプトを CLI ベースのデーモンとして実行しています。このデーモンは、独立したワーカー プロセスの監視/制御を担当します。

ユーザーは定期的に、PHP Web フロントエンド (CLI デーモンとフロントエンド コードは同じ物理サーバー上にあります) を介してワーカーを管理する要求を発行します。フロントエンドは、デーモンへのメソッド呼び出しを行う必要があります。

これらの「リモート」メソッド呼び出しを処理する方法について混乱しています。標準の UNIX または TCP ソケット上で JSON-RPC などの RPC プロトコルを使用するのがよいと思いましたが、PHP 用の JSON-RPC、XML-RPC、SOAP などのすべての実装は、 HTTP。私は Web 経由で通信していないので、HTTP はまったく不要です。

だから、2つの質問：

• ほとんどの PHP RPC パッケージが HTTP に結合されているのはなぜですか?
• 上記のようにメソッド呼び出しを処理する最良の方法は何ですか?

JSON-RPC は手続き型であるため、JSON-RPC にマップされない C# の API があります。JSON-RPC では、オブジェクト指向 API をどのように表現しますか?
もちろん、リクエストが次のようになるように JSON-RPC 拡張機能を使用できます。

しかし、それはハックのように感じられ、定義するために多くの作業が必要です。パラメーターとして含めることもできますが、これも適切ではありません。
JSON-RPC を使用したオブジェクト指向 API に対する作業に関するベスト プラクティスはありますか?

私は、クライアント/サーバー通信に AJAX 技術を幅広く使用する Web アプリケーションに取り組んでいます...特に JSON-RPC です。Zend Framework はサーバー側で使用されており、私が使用したい素敵な JSON-RPC サーバーを提供しています。

私の目標は、不要なコードの重複なしに、サーバー側の機能の大部分をクライアント側 (javascript) に公開する保守可能なシステムを構築することです。ZF の JSON-RPC サーバーの使用方法に関するブログ記事やチュートリアルを数多く見てきましたが (こことここを参照)、それらはすべて、一般に使用できる小さな API を公開することを目的としているように見えました。コードの重複はよくあることです。たとえば、あるブログ投稿で次のメソッドが公開されています。

setTitle2つの方法があるという事実は好きではありません。1 つのメソッド シグネチャが変更された場合、もう 1 つのメソッドの同期を維持する必要があります... API が広範囲に及ぶ場合、保守性の悪夢のように思えます。Book1 つのメソッドを持つ 1 つのクラスが必要であるように私には思えsetTitleます。

@export私の最初の考えは、公開したいメソッド/クラスにdocblock 注釈を追加することです。メソッドを公開することに決めたときsetTitleは、新しいメソッドではなく、注釈を追加するだけです。

私が見ている潜在的な問題の 1 つは、オブジェクトの永続性に関するものです。サーバー側では、オブジェクトの title プロパティを設定することは理にかなっていますが、が呼び出されるsetTitleまでデータベースに保持しないでください。update()クライアント側の呼び出しsetTitleは、すぐにデータベースに影響を与えるはずです。考えられる解決策の 1 つは、すべてのアクセサーを変更して、オプションの 2 番目のパラメーターを取り、変更によってデータベースがすぐに更新されることを示すことです。

ある種のプロキシ クラスは$persist、すべてのクライアント側の RPC 呼び出しに対してフラグが設定されるようにすることができます。

もう 1 つの問題は、PHP オブジェクトのシリアル化です。サーバー側では OO スタイルの呼び出しを行うのが理にかなっていますが、状態がないため$book->setTitle("foo")クライアント側book.setTitle(1234, "foo")(1234 は本の ID) では理にかなっています。これに対する私の解決策は、前述のプロキシクラスが何らかの形で次のようになることを担当することbook.setTitle(1234, "foo")です。

この問題は以前に取り組まれたり、議論されたりしたにちがいないような気がします...しかし、オンラインで多くのリソースを見つけることができません. これはまともな解決策のように思えますか?

こんにちは私はツイストjsonrpcサーバーへのrpc呼び出しを行ういくつかのマイクロコントローラーにサービスを提供するツイストに基づくrpcサーバーの開発に取り組んでいます。ただし、アプリケーションではサーバーがいつでも各マイクロに情報を送信する必要があるため、マイクロからのリモートjsonrpc呼び出しからの応答が、ユーザー。

私が今持っている結果は、マイクロが悪い情報を受け取っているということです。なぜなら、ソケットから来ているnetstring / json文字列が以前の要件からの応答なのか、サーバーからの新しい要求なのかわからないからです。

これが私のコードです：

JSON-RPCサービスを呼び出す場合、JavaScriptクライアントから一意のIDを生成する最も一般的な方法は何ですか？

改訂された質問：

通常、JavaScript JSON-RPCクライアントはカウントidパラメータを実装します（たとえば、最後のリクエストがid=1であり、応答が返されなかった場合、次のリクエストはid=2です。のリクエストid=1が応答した場合、次のリクエストを再度行うことができますid=1）。私は人々が通常これをどのように実装するかを理解することに興味があります。

私はiPadプロジェクトに取り組んでおり、このプロジェクトはjson-rpcWebサービスと通信する必要があります。Webサービスは、モジュール：cckおよびビューを備えたDrupalに基づいています。

1）jsonオブジェクトをWebサービスにプッシュする必要があります2）Webサービスからのコールバックデータが必要です

私はすでにSBJSONAPIとhttps://github.com/samuraisam/DeferredKit/apiをiPadプロジェクトに実装しています。

SBJSON APIは正常に動作し、これを理解しています。SamuriaisamDefferedKitは私にとって新しいものです。

私の質問は、このjson-rpc Webサービスからデータを取得する方法ですが、誰かにサンプルコードがありますか？または、ObjectiveCを見つけることができるいくつかの場所-json-rpcWebサービスのドキュメント。

敬具、

バートスクーン

- - - - -アップデート - - - -

私は今このコードを使用しています：

これにより、サーバーから次のメッセージが表示されます。

- - - - -/アップデート - - - -

なにが問題ですか？誰かがこれを経験したことがありますか？

敬具、

バートスクーン

ここの仕様によると：http://groups.google.com/group/json-rpc/web/json-rpc-2-0

より具体的には、このセクション：

存在する場合、rpc 呼び出しのパラメーターは、構造化された値として提供する必要があります。配列による位置指定、またはオブジェクトによる名前指定のいずれかです。

私には、両方のスタイルをサポートする必要があることは明らかですが、バグ レポートを提出したところ、別の開発者は、どちらの方法をサポートするかを決定するのは開発者次第であり、仕様では両方を必要としていないと感じています。

上記で引用した以外に、他の開発者が私と同じように解釈しない公式の回答が見つかりません。

それで、一般的なコンセンサスは何ですか？