解決的API自己的超媒體鏈接

比方說，我們有一個RESTful API方法：解決的API自己的超媒體鏈接

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

你可以看到address有一個鏈接到另一個資源。

要解決資源的address_id，應在服務器：

分手的URL，並確定路線
甚至使捲曲請求本身的「ID」的一部分，爲了獲得該鏈接資源的address_id？

來源

2013-05-16 eoinoc

你問什麼是正確的方法？從哪個角度來看？ – filip26

我覺得，你可能會做，那＃2是應該做的方式，和＃1基於內部知識只是一個黑客。如果客戶端發送了一個絕對URI的href，http://yoursite.com/addresses/2，你仍然想要使用＃1，並嘗試檢測ID？
讓我們假設您的網站用定義和記錄的MIME類型發送地址資源表示。如果客戶端發送指向第三方URI的href值，該值也會返回該格式的響應，並假設您希望支持該格式。無論如何你必須實施＃2。在這種情況下，不是沒有理由將它用於您自己（性能是主要的）。

說實話，我可能要做的就是和＃1一起去，直到出現＃2的需求。

來源

2013-05-28 08:25:30

聽起來合理。對於一個應用程序必須通過HTTP說「自己」來說，它會感覺有點多。如果構建在基礎API（如Twitter.com）上的應用程序通過HTTP調用自己的任何想法？ – eoinoc

許多客戶端 - 服務器應用程序（我主要考慮多人遊戲）通過TCP/IP與本地主機通信。當發生這種情況時，現代操作系統會將網絡堆棧短路，並且您可以獲得與IPC插座相同的效果。在Apache之前有一個輕量級的反向代理（如Nginx或Lighttpd）意味着大部分HTTP成本被否定，但是您仍然必須支付IPC的懲罰，而不是在一個流程中做所有事情。好處是你只有一個代碼路徑來處理「數據請求」。 –

解決的API自己的超媒體鏈接

回答

相關問題