SOAPクライアントをWordPressプラグインに埋め込みますか?


16

WordPressプラグインリポジトリを介して配布するWordPressプラグインにSOAPクライアントを埋め込む最良の方法は何ですか?使用するのが最善ですか?

さらに、なぜあなたがすることをお勧めしますか?そして、それぞれの長所と短所は何ですか。広く分散したプラグインでSOAPクライアントを使用した実際の経験がある場合は、「ボーナス(カルマ)ポイント」。また、.NET SOAPサーバー、Java SOAPサーバー、またはその他のSOAPサーバースタックの呼び出しに違いはありますか?

これは、「SOAP Webサービスにアクセスするプラグインを配布する際の落とし穴」という質問に関連する質問です。私もこのコミュニティwikiを作っています。

更新

この同じ質問を調査している他の人にとって役立つ可能性のあるリンクを次に示します。

回答:


2

特定のSOAPライブラリを抽象化して、後でより多くのクライアントのサポートを追加できるようにします。WP_Http複数のHTTP実装のプロキシと同様に、サーバーの機能に応じて選択します。

以前にこれらのライブラリのいくつかで遊んだことがあるに違いないが、どれを覚えていない。一般に、最新の状態に保たれ、余分なオーバーヘッドを必要としないため、外部コードよりもPHPモジュールを含めることを好みます(フレームワークの一部を使用するためにフレームワークをブートストラップする必要がある場合があります)。

長所と短所を追加できるように、各ライブラリの回答を作成することをお勧めします。または、このより一般的な質問は、「実際の」スタックオーバーフローにより適していますか?


答えてくれてありがとう。抽象化するのは良いことですが、すぐにではないことに同意します。いくつかの図書館でかなりの経験が必要だと思います。さもなければ、YAGNI原則に違反するリスクがあります。私はStackOverflowで尋ねましたが、彼らは抽象的な用語で議論し、WordPressプラグイン開発者が考慮すべき制限を知りません。ところで、あちらではあまり役に立たなかった。私が本当に望んでいるのは、すべてのクライアントがSOAPとRESTful Webサービスの問題を求めていることを認識することです。
MikeSchinkel

@Mike:確かに、重要な違いは、これはあなた自身のプラグインのためのものであり、他の人が拡張するAPIではないということですか?そうすれば、実際には、後で内部コードを変更して抽象化する自由が増えます。
1月ファブリー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.