我正在構建一個以API爲中心的Web應用程序，但我在解決某些業務邏輯時遇到了麻煩。如何在構建REST API時管理業務邏輯
採取這種使用情況：
POST /companies -> User adds a new Company which has a Location
（公司實體都有一個位置實體，保持公司的地址，一個公司有一個位置，位置可以有多個公司）
PATCH/PUT /companies/{id} -> User edits a Company information (changes street name from Company->Location
我希望我的API能夠檢查該位置是否已有其他公司。 如果是這種情況，我希望用戶選擇編輯位置實體（其將對該位置上的所有公司進行更改）或創建新的位置。
如何以RESTful方式將此選項發送回用戶？
容易：
PUT更換整個資源，如果它存在，或創建如果它不存在的新資源。如果你想嚴格遵守REST（沒有必要），就沒有其他選擇可供選擇。在你看到公司存在之前，用戶可以檢查公司是否存在GET。
POST是想替換所有公司收集的。您可以使用PATCH更新現有公司。
的REST API或任何嚴格的服務將提供基於請求的響應。因此，如果其他公司與該位置相關，則REST API肯定能夠回覆用戶。但API沒有辦法選擇迴應。 API可以回覆一些信息，用戶需要根據該信息提出另一個請求。
相反，最好給予用戶預先指定的選項。因此，相關公司是否應該更新位置的選擇是由用戶提出的，作爲請求的一部分。例如，用戶可以將其指定爲REST API上的查詢參數，並且該服務可以根據該查詢參數採取適當的操作。
所以也許一個GET/location/{id}/sites首先看看有多少公司正在使用這個位置，如果這是> 1，我的前端（AngularJS）會觸發一個選擇來做POST/location（Create一個新的位置），然後是PATCH/company/{id}/site（將網站更新到新的位置）或PATCH/location/{id}以更新原始位置。這是一個正確的RESTful方法嗎？ – Simon 2013-04-12 07:57:56
但這不是關於公司，而是關於位置。一個地點有多個公司。如果用戶更改位置，我需要知道他是否真的想要更改位置實體（所有關聯的公司都將具有編輯的位置數據）或創建新的位置。 – Simon 2013-04-11 12:20:16
我認爲您的數據模型存在問題。爲什麼一個地點有多家公司？它應該是相反的。你叫什麼位置？ – mpm 2013-04-11 12:54:46
其實公司有多個網站（例如總部，工廠1，工廠2）。公司和網站有一對多的關係。網站與位置具有多對一的關係（位置可以有多個網站）。如果您更新給定公司的位置（與網站設置的關係），我想檢查用戶是否想要使用網站更改附加到該位置的所有公司的位置，或者創建新位置但保留同一網站。 – Simon 2013-04-11 12:58:11