ふざけんな　そのAPI　クソすぎる

昨日の話ですよ。
仕事中に寝ていたら、あまりにも酷い夢を見てしまい、思わず教養溢れる私は、件名のような一首をしたためてしまいましたよ。

夢の中の仕事っていうのはですね、システム開発をしているんですよ。システム開発。
要はプログラマでいいのか、デジタルドカタと言えばいいのか、エンジニアといっても良いのかわからないけど、とにかくシステムを開発しているんですよ。ディペロップですよ。コンストラクトですよ。
今月リリースするシステムですよ。

でね、最近のシステム開発では、最近といっても私は20年以上も前からこんなシステムばっかり作っているんですけどね、APIというのがあるんですよ。えーぴーあい。アピ。
説明するのがめんどくさいけど、APIっていうのはですね、システム間で情報をやり取りするんですよ。システム間なら情報をやり取りするのって当たり前じゃないですか。その、当たり前のことをやるんですよ。
読んでる方は訳わからないかもしれないですよね。大丈夫ですよ、書いている方も訳わからない。
でね、APIでシステム間の情報をやり取りをするんですけどね、その情報って、テキストなんですよ、テキスト。文字列。文字の列挙。
例えば、こんな感じ

{
    "名前":"ikirasi",
    "年齢":48,
    "誕生日":"2月3日"
}

こういうテキストをシステム同士でネットワークを使ってやり取りするんですよ。
例えば上のテキストなら「ikirasi」って名前の人で、年齢は48歳で、誕生日は2月3日ですって、情報ですね。
例えば、情報を渡す側のシステムは画面でユーザーに情報を入力させる画面で、情報を受け取るシステムは受け取った情報をデータベースに入れるシステムと思えばいいですかね。
システムをこういう風にわけておけば、データベースに入っているこの"ikirasi"て名前の人の情報を、ほかのシステムからでも見えるようになるし、別のシステムからでも"ikirasi"って人の情報を直したり、今度は"好みのタイプ"とかの情報を"ikirasi"の情報に加えることもできる。
ちなみに、この記事を投稿しているのも2月3日で、今日は私の誕生日ですよ。
そして、これがAPIなんですよ。
こういうフォーマットといって、テキストのルールですね。これをJSONと言って、JSONってJavaScriptって言語があってねって話があるんですけど、それはどうでもいーんですよ。

それでね、システム同士はこういう情報をやり取りするんですけどね。
こういう情報って、繰り返しの情報を渡したくなるんですよ。
例えば、人の情報なら、好物って二つ以上あるじゃないですか。
それを、こういうふうに書いてしまうと、システム的には非常に困る。

{
    "名前":"ikirasi",
    "年齢":48,
    "誕生日":"2月3日",
    "好物１":"ラーメン",
    "好物２":"二郎ラーメン",
    "好物３":"牛丼"
}

人間がね、こういう情報を読んだらね、この人の好物は「ラーメン」と「二郎ラーメン」と「牛丼」なんだなってわかるんですけどね、システムって基本バカなんで。好物１と好物２と好物３が同じ好物だってわからせるのは大変なんですよ。めんどくさい。
だからね、こう書くんですよ。

{
    "名前":"ikirasi",
    "年齢":48,
    "誕生日":"2月3日",
    "好物":["ラーメン", "二郎ラーメン", "牛丼"]
}

こうやってね、"["という括弧でね、これって大括弧っていうの？スクエアブランケット？なんでもいいけどね、"["と"]"で囲んでね、","で区切って二つ以上書けるようにする訳ですよ。
そうするとね、この"ikirasi"って人の好物は「ラーメン」とその他省略なんだなって、システムさんはわかってくれるんですよ。
こういうのを配列というんですよ。
これ大事なんで覚えておいてくださいね、テストに出るんで。

で、情報をやり取りするのはシステムなんですけど、そのシステムを作っているのは人間な訳で、情報をやり取りするルールは人間同士が決めるんですよ。
めんどくさいですよね。ルールを決める。決められたルールを守る。

それでね、上のような情報をやり取りをシステム同士でする場合、API仕様書ってのがあるんですよ。「えーぴーあいしようしょ」っていうの？
例えば、こんな感じですよ。

• 名前：テキスト：人の名前

• 年齢：数字：人の年齢

• 誕生日：日付：人の誕生日

• 好物：テキストの配列：人の食べ物の好物

こんな感じの情報をね、Excelの表で作ってウヤウヤしく通信する同士のシステム開発者が作ったり見せあったりするんですよ。
それでね、API仕様書っていうのは、情報を受け取る方が書いて、情報を渡す方が読むんですよ。そんでもって、情報を渡す方は、このAPI仕様書を読んで、ルール通りにシステムに情報を渡すように情報を渡す方のシステムを作るんです。

でね、上のようなAPI仕様書をもらうとですね、システム開発者というのはですね、「あー、『好物』っていうのは配列だから、複数入れていいのね」って、思うんですよ。これは本能なんですよ。常識なんですよ。

それで、このAPI仕様書を書いたシステムに情報を渡すシステムを作る訳ですよ。

やっと本題に入るわけですけど、夢の中では、今月リリースのシステムですよ。
もう、テストは全部終わっているシステムですよ。夢の中では。
で、このシステム開発で、該当の箇所って私が作った訳じゃないけど、なぜか問題があったらお前が直せって言われているんですよ。夢の中。
それでね、上のようなAPI仕様書で情報を渡すプログラムが、夢の中ではあった訳ですよ。
でもね、テストは終わっているんだけど、受入試験ていうシステムを使う人が実際に使ってみる工程があってですね、それを夢の中でやっていてですね、上のようなAPI仕様書で「好物」って情報に「らーめん」と「弁慶ラーメン」と「すた丼」とか入れて相手のシステムに送るんですよ。
そうしたらですね、相手のシステムには「好物」に「らーめん」しか届いていないことがわかった。

おかしいですよ。バグですよ。リリース失敗ですよ。夢なら覚めてほしいですよ。

でね、こっちで作ったシステムをどんなに調べても、「好物」には「らーめん」と「弁慶ラーメン」と「すた丼」とちゃんと入っている。配列形式のテキストになっている。

間違ってねーじゃん。おかしくねーじゃん。ってなるんですよ。

これは夢だからしょうがないけど、夢だと理不尽に思い通りにならないことってありますよね。悪夢ってやつ？

それでね、API仕様書を読み間違えたんじゃないかと思ってね、読み直したんですよ「えーぴーあいしようしょ」
そしたら、どうですか？こんなことが書かれていたんですよ。

• 好物：テキストの配列：人の食べ物の好物（ただし件数は1件まで）

わかりやすいように太字にしましたけどね。本物は太字になんてなっていないですよ。
でも、書いてある。ちゃんと書いてある。本当に書いてある。
配列なのに、1件までなんですよ。1件。0でも3でもない、1だよ1。

配列なのに1件までっていうのが既におかしいんですけどね、普通はAPI仕様に違反をした情報を送ったらね、送られたシステムは400エラーってのを返却するんですよ。400ってのはBadRequestってこと。覚えづらけりゃ、バッドコミュニケーションでもいいよ。
なのにね、夢の中ではですよ。400エラーなんて返さずにですよ。さも正常に受け取ったふりして、先頭の1件しか処理してくれないんですよ。
するとね、テストでも正常なんだから気付けないんですよ。
それがね、リリース直前になって気づいちゃった。

これね、どう酷いのか、システム開発を知らない人にはわからないだろうから、わかりやすく書くとね、
スーパーで最近、セルフレジってあるじゃないですか。自分で商品のバーコードを機械に読ませて清算するの。
あれでね、買いたい商品を全部バーコードで読ませて精算しようとするじゃないですか。普通スーパーで何か買う時って一つだけって珍しいじゃないですか。何個も買いますよ。でもね、何個も商品のバーコードを読ませて、さて精算しようとすると、機械が
「お前、いっぱい商品を登録したみたいだけど、最初の一つしか精算してやらねーよ、他のも買いたきゃ、一つずつ精算し直しな、バーカwwwwwwwww」
っていうようなもんなんですよ。
ムカつくでしょ？こんなこと機械が言い出したら。
俺だったら、店長呼んで首絞めますよ。もう、刑務所に入ってもいい。

でもね、API仕様書っていうのがあって、そこに書いてあると、それを読まなかったこっちが悪いってなっちゃうの。
しかも、テストが終わっているのにバグが見つかると、夢の中だとすげー怒られるの。

クソでしょ？くそ！

でもね、こんな不条理が罷り通っているんですよ、夢の中のシステム開発って。
二週間前にお寺で座禅を覚えて幸せになれるかと思ったけどね、システム開発やっていて幸せにはなれないなー。