解析API'；我们自己的超媒体链接

假设我们有一个RESTful API方法：

POST /people
{
    "name" : "John",
    "_links" : {
        "address" : {
            "href" : "/addresses/2"
        }
    }
}

您可以看到

address

有一个指向其他资源的链接

要解析该资源的

地址\u id

，服务器应：

分解URL并标识路由的“id”部分

甚至向自身发出一个curl请求，以获取链接资源的

地址\u id

---

我觉得#2是应该做的#2#和#1只是一种基于内部知识的黑客行为。如果客户端发送的href是绝对URI，您是否仍要使用#1并尝试检测ID？
让我们假设您的站点发送具有定义和文档化MIME类型的地址资源表示。如果客户端发送一个指向第三方URI的href值，该URI也返回该格式的响应，并且假定您希望支持该格式，该怎么办。无论如何，你都必须实施2。在这种情况下，几乎没有理由不为自己使用它（性能是主要原因）

---

老实说，我可能会选择1，直到需要2为止。

你是在问什么是正确的方法吗？从哪个角度看？听起来很合理。应用程序必须通过HTTP与“自身”对话，这会让人感觉有点不舒服。如果基于基础API（如Twitter.com）构建的应用程序通过HTTP调用自己，有什么想法吗？许多客户机-服务器应用程序（我主要考虑的是多人游戏）通过TCP/IP与本地主机通信。当这种情况发生时，现代操作系统会使网络堆栈短路，您可以获得与IPC套接字一样好的东西。在Apache前面使用一个轻量级反向代理（如Nginx或Lighttpd）将意味着大部分HTTP成本被抵消，但与在一个进程中完成所有工作相比，您仍然需要支付IPC罚款。好处是您只有一个代码路径来处理“数据请求”。