Subbu Allamaraju氏は、標準メディアタイプvs.カスタムメディアタイプ、およびこれらを使う際のベストプラクティスを決めようという、RESTコミュニティで繰り返し議論されている話題のひとつを再び取り上げた。彼はメディアタイプの使用を、２つの見方に分けるところから始めた。
- 意見１：RESTfulなWebサービスにするため、Webサービスは標準のメディアタイプを使わなければならない。
- 意見２：カスタムメディアタイプは相互作用を「見える化」し、コントラクトとしての役割を果たす必要がある。
最初の意見は、より厳密に言うと、Roy Fieldings氏の論文で述べられている“application/vnd.example.myway+xmlのようなメディアタイプを使うのはRESTfulではない”をベースにしている。Subbu氏は、現実にこのようなメディアタイプを使うことによる影響を理解することの方が、論文に文字通り従うよりも重要であると考えている。しかし、論文の解釈についてもっと議論した方がよい、という提案もコメントされている。
２番目の意見で彼は、カスタムメディアタイプの使用が、プロトコルレベルのメッセージの「見える化」につながる、と述べている。
[…] 例えば、もし
application/xmlを使っていたら、メディアタイプが注文書を表しているのか、それともフォトアルバムを表しているのか、どうやって知ることができるのでしょう？ Webサービスがapplication/vnd.example.poやapplication/vnd.example.albumといったメディアタイプを使っていれば、データの中身を解析しなくても、データが何を表しているのか分かります。この考えによれば、メディアタイプはメッセージの意味の識別子であり、メッセージを受け取る側は処理コードを書くきっかけとしてメディアタイプを使えます。
“それで、結局どうするのが正しい？” 彼は、自身の４つの考えを挙げ、ベストプラクティスを民主的に決めようと努力している。
- 送信者が、XMLやJSONといった標準的で拡張可能なフォーマットを使ってデータをフォーマットするなら、
application/xmlやapplication/jsonなどの標準メディアタイプを使いましょう。- 新しいフォーマットを作るなら、新しいメディアタイプを作りましょう。
- XMLやJSONのメッセージの代わりに、アプリケーションレベルで情報を交換する方法を探しているなら、他のものを使いましょう（例えば、XML名前空間や規約）。
- バージョニングが目的であれば、URIでバージョニングしましょう。
Java風の例を挙げて、彼は、メッセージをリクエストがどうやって処理されるかを理解するために、メッセージを覗けたとしても、場合によっては「見える化」されないと表明している。
application/xmlやapplication/jsonといったメディアタイプは、コード中でXMLやJSONメッセージが処理されるのには十分です。[…] URIベースのアプローチはスタックを横断して動作することが保障されます。"きれいなアーキテクチャ"や"RESTfulコントラクト"のために、現実の相互運用を無視することは、結局裏目に出るでしょう。
Subbu氏の投稿を通じて示された彼の解決方法は、アーキテクチャ上の純粋さと現実的な相互運用との間の、適正なバランスになっているだろうか？ オリジナルの投稿を訪れ、あなたの意見も議論に加えて欲しい。