応用#✎

[5] 応用規格として、 XMLStorageSystem, Blogger API, MetaWeblog API, Pingback などがあります。

[15] BEEP

関連#✎

[13] SOAP は XML-RPC を置き換えることも狙っていたようですが、 結局置き換えることはできずにどちらも廃れました。

歴史#✎

• [1] XML-RPC Specification http://www.xmlrpc.com/spec
• [2] XML-RPC 仕様書 http://lowlife.jp/translation/xmlrpc_spec.html

• [4] 仕様書見たんだけど、使えねぇってオモタ。
  • string 要素型は「ASCII 文字列」。 (非 ASCII には base64 要素型を使えばとか思ってそうで怖い。)
  • 当然 Content-Type: 欄の charset パラメーターには言及なし。
  • というか媒体型は text/xml だ。せめて application/xml にしる! と思うんだけど、しつこく text/xml だ! と言ってる以上そうするしかない。
  • 日付の時間帯はどうなのだ? という質問に、それはサーバーが勝手に決めるんだ! と答えている。相互運用性について真面目に考えているんだか問詰めたいところだ。
  • データ型は名前空間使って拡張できた方が良さそうなもんだが。
  • 仕様策定は1999年か。当時の状況ではやむを得ないこともあるのかな?
  • なんにせよ、喜んで使うのは XML厨と blogger くらいだろう。他に使う香具師がいたとすれば嫌々だろうな。

• [6] >>4 時間帯のは多分、そういう系(謎)の規格によくある、「情報交換の当事者間の合意」のことだと思われ。で、その当事者間の合意は、事前にサーバーから仕様書として通知されているものだ、と。
• [7] >>6 どうせ XML-RPC はサーバー‐クライアント通信のためのメタ・プロトコル (実際のプロトコルの一つ下の層。) なだけでその通信内容なんてどうせ好き勝手なんだろうし、時間帯も好き勝手にしろよ、ってことなんだろうなあ。
• [8] でも時間帯という重要なパラメーターを仕様依存にしてしまうと、例えば汎用 XML-RPC モジュールがあったとして、ある言語の日付型を内部で XML-RPC の dateTime.iso8601 型に変換する時に、どうしたもそのパラメーターを知らないといけない。ちょっと面倒だと思うのね。ちょっとだけど。

[9] (開発者さま向け)はてなブックマーク件数取得APIに新しいAPIを追加 - はてなブックマーク日記 - 機能変更、お知らせなど (8/11/2009, 4:25:42 PM 版) http://hatena.g.hatena.ne.jp/hatenabookmark/20090811/1249961864

[10] Ruby ではてなブックマーク API を叩く - Life like a clown ( (2/19/2011, 1:29:45 AM 版)) http://d.hatena.ne.jp/tt_clown/20110118/1295326025

[11] draft-salzer-xmlplusrpc-01 - XML+RPC - XML marshalled Remote Procedure Calls (10/20/2014, 4:57:59 AM 版) http://tools.ietf.org/html/draft-salzer-xmlplusrpc-01

[12] Specification for Fault Code Interoperability, version 20010516 ( (1/2/2015, 9:26:19 AM 版)) http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

[14] RFC 3529 - Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) (2/7/2016, 8:22:13 AM 版) https://tools.ietf.org/html/rfc3529