APIを自らRESTfulだと称してはいけない – このアドバイスは，Nodeup podcast - an APIs showの先日のエピソードで，API開発者たちが語った中のひとつだ。そのポッドキャストでは，Nodeupのホストを務めるVoxerの技術者Daniel Shaw氏，Browserlingの創立者James Halliday氏，そしてゲストのMark Cavage氏とAndrew Sliwinksi氏を交えた会話を繰り広げている。Cavage氏はクラウドインフラストラクチャのプロバイダ Joyentのソフトウェア技術者で，Node.jsのパッケージRestifyの作者でもある。JoyentはNode.jsを所有すると同時に，広範囲に活用している企業だ。もうひとりのSliwinski氏は，子供向け体験Webサイト DIY の共同創設者で，CTOを務める人物だ。
API設計の話題から始まった会話は，RESTの有用性やセキュリティ，テスト，ドキュメンテーション，スキーマやストリーミングなど，Node.jsを使ったAPI開発のおもな問題を巡って，とりとめもなく続いている。その中で，お勧めの手法としてあげられているのが "READ MEから始める" API設計という，あたかもユーザインターフェースを構築するような，API設計のアプローチ方法だ。Cavage氏はここで"プレスリリースを最初に書く"という ，Amazon.comのサービス開発アプローチを引き合いに出している。手始めに最小限の範囲で初期APIを構築して，利用経験をベースに拡張していくとよい，と氏は付け加えている。あまり多くの機能を，前もって準備しておこうと考えてはいけないのだ。
RESTの重要性については，さまざまな意見がある。APIがRESTfulであると称することの問題は，それに"釣り餌(troll bait)のような効果がある"点だ，とShaw氏は言う。皆，RESTかどうかということを気にし過ぎているし，こだわり過ぎている。それにも増して問題なのは，下位プロトコルとして一般的なHTTPへの固執だ。Cavage氏のアドバイスはこうだ： HTTPは "ファイアウォールに必要なインターフェース" ではあっても，内部的にはもっと効率的なデータフォーマット，妥当な通信手段はいくらでもある。"HTTPはコストの高い" プロトコルであることを忘れてはいけない。バックエンドインフラストラクチャとして使用可能なrpcフレームワークの例として，氏はdnodeやfastなどの名前をあげている。
APIセキュリティのテーマでは，いくつか議論が起きている。HallidayとShawの両氏は，OAuthなどの新しいセキュリティプロトコルが，curlのようなコマンドラインツールでAPIを使用する，これまであった楽しみを奪うことになるのではないか，という意見だ。これに対してCavage氏は，セキュリティは保護しようとするAPIの価値に見合ったものでなければならない，HTTPのベーシック認証では不十分なことも少なくない，と反論する。そのCavage氏が紹介しているのがHTTPシグネチャだ。パスワードより優れていて，しかも"他[のプロトコル]よりも簡単"だという。HTTPリクエストに送信元認証，メッセージ完全性，再実行耐性を追加するHTTPシグネチャはJoyentが開発したもので，先頃IETFに提出されている。
テストは実際のシステムとデータに基づくべきである，"モック利用"は望ましい方法ではない，という点では全員の意見が一致した。モックが問題なのはテストが現実から乖離するからだ，とHalliday氏は説明する。Sliwinski氏はDIYで行っているテスト方法について説明している。ライブデータをローカルデータベースに投入することで，モックに頼らずに継続的インテグレーションのテストを実行するのだという。使用しているテストツールはNodeunit, Tap, Travis CIなどだ。
ドキュメントに関する話題で，WSDLが"減点"を稼いでいる，とジョークを言うのはCavage氏だ。DIYでの氏らのやり方ではまず最初に，対話形式のドキュメントWeb ページを動作させるAPIの資料を，JSON仕様フォーマットで記述する。Joyentではドキュメントの記述にRestdownを使用して，APIと同じリポジトリに保存する，と氏はその方法について説明している。ドキュメントとAPIの整合性を保つことは重要な課題だ。また，サンプルデータを添付して，インタラクティブなドキュメントを用意することが望ましいという点では，全員の意見が一致している。
スキーマも問題となる部分のひとつだ。スキーマバリデータの大きな問題としてCavage氏があげるのは，処理が遅いこと，理解不能なエラーを投げることの２つである。しかしその一方で，正式な文法の定義もなく手作業で行うというのもリスクが多い。DIYではJSONスキーマを使用しているが，これは妥協の産物だ。というのも，標準がいまだ改訂中であるため，Node.jsにJSONスキーマバリデータの決定的な実装が存在しないからだ。JSVという実装があるにはあるが，エラーメッセージが理解しがたいものであるため，それをキャッチして再解釈するラッパを独自に書かなくてはならない，とSliwinski氏は言う。
Node.jsの非ブロックI/O アーキテクチャのメリットを活かしたストリーミングAPIに関しては，ポッドキャストでもたくさんの議論が交わされている。APIでJSONをストリームするのは，バッファリングやレイテンシ回避の方法としては理にかなっている，とHalliday氏は言う。Cavage氏も，それまで使用していたパッケージであるExpressからRestifyに代えたおもな理由のひとつとして，JSONストリーミングのサポートをあげている。ただし，Node.jsミドルウェアとJSONのストリーミングを併用する場合には，注意すべき点がひとつある。Cavage氏はConnetなど，ミドルウェアを好んで使用している。気まぐれなクライアントのセッション管理にまつわる"ユーザ処理の複雑性"を処理するためだが，それによってストリームを扱えなくなるという代価を払う必要がある，と氏は言う。ストリームをネイティブに処理するには，ミドルウェアなしの，コアなNode.jsが最適なのだ。
ここで今回の冒頭に上げた質問に立ち返ってみよう。自分のAPIがRESTfulであると称しても問題はないのか，あるいは単に，うるさ型のよからぬ行動を促すだけなのだろうか？ RESTは準拠すべき標準なのか，制約の集まりなのか？ RESTfulとそうでないものとは，どこで線を引けばよいのだろう？ 読者であるあなたの体験を聞きたいと思う。