すべてのWebアプリケーション（すべてのWebサイト）はサービスです。（...）WebサイトをWebサーファーが使いやすくする機能により、WebサービスAPIもプログラマーが使いやすくなります。
リチャードソンとルビー、「RESTFulWebサービス」
私が意図しているように、WebサービスでもあるWebサイトは、ユーザーエージェントが何を要求するかに応じて、そのリソースの複数の表現を提供します。APIは、いわばWebサイト自体であり、個別に提供されるものではありません。
これは、世の中に出回っている多くの人気のある「RESTAPI」には当てはまりません。たとえば、TwitterのAPIはhttp://api.twitter.com/1/にあり、URIの「1」はAPI自体のバージョンです。Socialcastは、 https： //demo.socialcast.com/api/でREST APIも提供します。第3レベルの名前は、アドレス指定するネットワークの名前です。
これは私には間違っているようです。http://www.example.com/blogにブログがある場合、ロボット専用のJSONを提供するために、別の場所にAPIを提供する必要はありません。http://www.example.com/blog/posts/とhttp://api.example.com/blog/postsの2つの異なるURIを使用する代わりに、前者だけを使用し、複数の表現を使用できるようにする必要があります。application/jsonユーザーに提供したいJSONAPIの場合。
例1：私のブログへの投稿を要求するブラウザ。
リクエスト：
curl -i \
-H "Accept: text/html" \
-X GET \
http://www.example.org/blog/posts/
応答：
200 OK
Content-Type: text/html; charset=utf-8
<html><body><h1>Posts</h1><ol><li><h2>My first post ...
例2：同じURIですが、今回はロボットがリクエストを行います。
リクエスト：
curl -i \
-H "Accept: application/json" \
-X GET \
http://www.example.org/blog/posts/
応答：
200 OK
Content-Type: text/html; charset=utf-8
{
"posts": [
{
"id": 1,
"title": "My first post" ...
APIのバージョン番号は、リクエストヘッダーの「Accept」フィールドにエンコードする必要があります。特に、TwitterのようにURIを強く入力することは避けてください（「statuses / show.json？id=210462857140252672」または「statuses/show / 210462857140252672.json "）。
統一されたアプローチを採用することで柔軟性を失う可能性がありますが（ただし、Cool URIは決して変更されるべきではありませんか？）、REST（または少なくとも私の解釈）を順守することでより多くのメリットが得られると思います。
APIとWebサイトを分離するか、それらを統合するか、どちらがより正しいアプローチですか？