悪いほうが良い原則とJSON

なんとなく改変コピペである（日本語版はこちらによった。ちなみに面倒そうな箇所は適宜はぶいている）

あるとき、MIT 出身と Berkeley 出身の二人の有名人がWebサービスAPIの問題を話し合うために集まった。 MITの彼は SOAP (XMLのRPCフレームワーク) に精通しており、JSONベースのRESTfulサービスのためのドキュメントを読んでいた。彼はJSONがどのようにスキーマ問題を解決できるかに興味を持った。スキーマ問題はサービス事業者が新しいWebAPIを定義するときに起こる。もしAPIの返す値にuserといったフィールドがあるとすると、その意味するものはユーザを指示するID値であったり、なんらかの文字列であったり、簡単なプロフィール情報を含むオブジェクトであったりする。しかしAPIの返すそうしたフィールドは通常ただの1つの名前しかないため、クライアントはその内部構造を把握することができない。そこでサービスは構造の意味をあらかじめクライアントプログラムの作者に伝えなければならない。 「正しい」やり方はもちろん、機械処理可能な構造の意味を表現するための手法を定め、URIによって指定できるようにすることである。
MITの彼は読んでいたJSONやRESTのドキュメントの中にこの問題に対処するセクションを見つけられなかったので、New Jersey側の彼にどうやってこの問題に対処しているのか尋ねた。New Jerseyの彼は、JSONでRESTfulなサービスを作っている人はこの問題に気付いているが、 解決はきちんとしたAPIドキュメントをつねにメンテしておき、そのドキュメントを公開しておくことだと答えた。したがって、正しいユーザプログラマはドキュメントを読んでどのフィールドをチェックするか自分で決めるものだと彼は言った。
MITの彼はこの解決は気に入らなかったが、それはもちろんこの解決が 「正しい」やり方ではないからだった。
New Jerseyの彼は、このJSONの解決は正しい、なぜならJSONの設計哲学は単純さにあるのであって、「正しい」ことをするのは複雑過ぎるからだと言った。 それだけでなく、プログラマがドキュメントを見てフィールド名などのチェックコードを入れることは簡単なことだと。
MITの彼はそれに対して、実装は簡単だが使用法が複雑すぎることを指摘した。New Jerseyの彼は、ここではJSONの設計哲学に従って適切なトレードオフが行われていると答えた。すなわち、実装の簡単さの方が使用法の簡単さより重要なのだと。
MITの彼はそれを聞いて「屈強な男がやわらかい鶏料理を作ることも 時にはあるものなのに」と嘆息したが、New Jerseyの男には理解できないようだった[筆者もよくわからない]。