過去数年に渡って、誰かがSOAのようなものやクラウド用にプロトコルとして、HTTP(そしてREST)を提案する毎に、HTTPはブラウザを念頭において設計されたので、非ブラウザクライアントには上手く合わない、という議論がなされてきた。けれども、JAX-RSと関連するフレームワーク のような標準と色々ある他の RESTfulアプローチによって、そのような懸念のために、ブラウザ外でその採用が鈍ることはなかった。Home Documents for HTTP APIsのドラフト提案の最近の発表に呼応して、IETFは更に非ブラウザクライアントを見据えている。この提案の中で、“application/json-home”フォーマットは、特定のサイトから入手できるリソースに加えて、そのようなサービスと、どのようにやり取りするかについて、可能なヒントも記述している。
GET / HTTP/1.1
Host: example.org
Accept: application/json-home
HTTP/1.1 200 OK
Content-Type: application/json-home
Cache-Control: max-age=3600
Connection: close
{
"resources": {
"http://example.org/rel/widgets": {
"href": "/widgets/"
},
"http://example.org/rel/widget": {
"href-template": "/widgets/{widget_id}",
"href-vars": {
"widget_id": "http://example.org/param/widget"
},
"hints": {
"allow": ["GET", "PUT", "DELETE", "PATCH"],
"representations": ["application/json"],
"accept-patch": ["application/json-patch"],
"accept-post": ["application/xml"],
"accept-ranges": ["bytes"]
}
}
}
}
RESTeasyリードのBill Burke氏は、提案を気に入っている がそれについて興味あるコメントをしている。
私はこのフォーマットが好きですが、個人的な意見では、hintsは必要ありません。ほとんど(99%?)の非ブラウザ クライアントは、既にリソースとどのようにやり取りスべきか知っています。それらが本当に探しているのはリソースの実際のURLです。IMO、別のフォーマットは、リソース記述のために定義されるべきであり、もし望むならLink Relation URLは、その表現を提供できます。これ（とAtom Link XMLフォーマットも）に関しての別の不満は、relationship, relの値はURLになり得ることです。それよりも、論理的な名前を定義し、relationshipを記述するURLを特定する別の特性を持つべきだ、と思います。アプリケーション、特にイントラベースのアプリでは、インターネットアプリよりもURLはもっと頻繁に変わります。論理名特性は、固定のままで、記述用URLはずっと動的あるべきでしょう。
そしてある評者が指摘したように、恐らくこの提案の本当に役立つところは、当該のサービスが人にとって読みやすく、理解しやすいことではないか。しかし、人が本当に JSON-HOME文書を読むだろうか？更にMike Kelly氏が言うように、
もし hintsをとってしまったら、 hal+jsonになってしまい、これは1年以上前からあるものです。http://blog.stateless.co/post/13296666138/json-linking-with-hal
今のところこれは、単にIETFのドラフトにすぎないので、今がフィードバックを返す丁度いい時である。