bouzuya/rfc6570-expand を RFC 6570 URI Template level 4 に仮対応させた。実装の進捗や感想および RFC 6570 の問題点を書く。
bouzuya/rfc6570-expand は RFC 6570 URI Template を展開するための npm package 。RFC 6570 のことは 2016-05-28 に書いた。そちらに覚書である Gist の URL や npm package を検証した repository URL も掲載している。
さて、冒頭で「仮」対応としたのは RFC 6570 に記載されている例の中でも簡単なものだけを test に追加して通すように直しただけだからだ。現状、厳密な意味では仕様に準拠していない。まだ実用段階にないので npm publish していない。
RFC 6570 は level 3 / level 4 あたりから複雑さが気になる。なぜ :max-length や * での Array / Object の特殊な展開が必要だと思ったのか。展開の規則も嫌に複雑というか、使う側も分かりづらい気がするのだけど……。bouzuya/rfc6570-expand はこのあたりの実装が特に雑だ。
現状の実装について。環境は Node.js + TypeScript + Typings + eater + power-assert 。
Node.js は v6.1.0 にして ES2015 をほとんど使える前提で書いている。Transpile せず TypeScript で "module": "commonjs" かつ "target": "es2015" してある。普段は babel で transpile するか "target": "es5" するのだけど、面倒なのでこうしている。
testing には eater + power-assert を使っている。 yosuke-furukawa/eater の検証は今回の主目的と言ってもいい。いまのところは良い印象を持っている。 AVA から乗り換えようと思っている。余計な機能がないし、Source Code をすべて読んでから使っていることもあって安心感がある。.d.ts が提供されていないことと reporter の弱さが気になる。 reporter はあとで自作したい。
今回の実装で面白いのは uri-templates/uritemplate-test という RFC 6570 に記載されている例やその他の Test case が用意されていることだ。このおかげで仕様書をななめ読みして、あとは test 書いて通すだけの game と化している。ぼくは 4Clojure を思い出した。いわゆる Koans だ。こういう仕組みはとてもいい。言語をまたいだ実装も安定する。
ちなみに、下記の Gist に書いた npm package のほとんどがこの test に通らない。
RFC6570 - URI Template のための npm package に関する覚書
一部の npm package には Pull Request を送った。bramstein/url-template#15 / bramstein/url-template#16 / LuvDaSun/rfc6570#7 / LuvDaSun/rfc6570#8 。
test に通らない主な原因は URL (URI) の定義である RFC 2396 / RFC 3986 / URL Standard の非互換性だ。 RFC 6570 が参照しているのは RFC 3986 なので、準拠をうたうなら RFC 3986 に従う必要がある。一方で JavaScript の encodeURI や encodeURIComponent は RFC 3986 とは異なる挙動だ。おそらく RFC 2396 が基なのだろう。URL Standard についてはよく分からないが実際に動いているものを基準に定められているように思うので、RFC 2396 に近いものだと予想している。つまり RFC 6570 に準拠すると仕様上は正しいが一般的な URL からずれたものを使うことになる。
「地獄っぽい」という感想が浮かぶ。ひとまず RFC 3986 準拠、RFC 6570 準拠でつくり、 RFC 3986 と URL Standard の非互換性を補うための option で対応するつもりだ。
