每个 Web 应用程序 - 每个网站 - 都是一项服务。(...) 使 Web 站点易于网络冲浪者使用的特性也使 Web 服务 API 易于程序员使用。
Richardson 和 Ruby，“RESTFul Web 服务”
正如我所期望的那样，一个同时也是 Web 服务的网站根据用户代理请求的内容提供其资源的多种表示形式。API，可以这么说，是网站本身，并不单独提供。
许多流行的“REST API”并非如此。例如，Twitter 的 API 位于http://api.twitter.com/1/，URI 中的“1”是 API 本身的版本。Socialcast 还在https://demo.socialcast.com/api/提供了一个 REST API ，第三级名称是它所寻址的网络的名称。
这对我来说似乎是错误的。如果我在http://www.example.com/blog有我的博客，我不需要在不同的位置提供 API，只为机器人提供 JSON。与其拥有http://www.example.com/blog/posts/和http://api.example.com/blog/posts这两个不同的 URI，我应该只拥有前者，并且可以使用多种表示形式，其中application/json对于我希望提供给我的用户的 JSON API。
示例 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 和网站，还是统一它们？