嗨，我一直在尋找網絡來搜索儘可能多的信息，我可以讓我的工作人員在Yii框架中創建一個寧靜的服務器。Yii中的REST風格的服務器設計
我發現迄今已經處理了寫一個RESTful應用程序，與一個模型（即主題或主題）
我的問題的關鍵是這一交易的所有的例子，我應該如何處理寫一個寧靜處理很多模型類型的服務器，即客戶端，品牌，項目，任務？
每個模型對象都需要執行CRUD操作，例如 要創建一個新品牌，系統需要客戶端ID以及其他CRUD操作。
每個模型對象應該有自己的RESTFUl服務器還是應該有一種控制器將RESTFUL請求路由到模型對象的相應Rest控制器？ 如果有一臺服務器動態地決定什麼樣的模式來與像一個開關（並不熱衷於這種想法個人）
任何一種如何實現這種REST架構的將是真正偉大的意見的工作
我認爲還值得注意的是，我正在構建的服務器將在前端使用sproutcore，並且只會返回JSON，因此不需要任何格式檢測。
通過此運行tutorial。只需複製控制器操作。編輯第二組操作以與新模型進行交互。例如，本教程要求在控制器中創建以下操作：
public function actionList()
{
}
public function actionView()
{
}
public function actionCreate()
{
}
public function actionUpdate()
{
}
public function actionDelete()
{
}
您將爲您的第二個模型創建替代操作。例如：
public function actionListB()
{
}
public function actionViewB()
{
}
public function actionCreateB()
{
}
public function actionUpdateB()
{
}
public function actionDeleteB()
{
}
如果您需要更多信息或澄清請發表評論。祝你好運。
嘿謝謝你的答案我開始認爲我不會得到一個：D這個過程是沿着我在想什麼，但是你能否向我澄清爲什麼簡單地將Yii後端作爲普通IE構建起來會更好，讓所有控制器按照正常方式佈局，並簡單地提供一種統一的方式來訪問所有帶有Url routinig的控制器，而不是有一個巨大的Api控制器，對於每個將要使用的模型都進行CRUD操作？ –
即時通訊只是想了解最好的方式來讓這個應用程序是可擴展的等也考慮到這個應用程序將只服務器作爲sproutcore前端的後端，它不需要作爲一個普通的Web應用程序在渲染視圖等方面，只需調用預定義的url即可執行特定的任務，並只返回url中指定格式的數據 - 非常感謝您的幫助！ –
我的錯。你是對的Api控制器。擁有一個巨人是沒有意義的。砍掉它肯定會更好。 –
我在Yii開發RESTful應用程序。到目前爲止，一切都很好。
模型。我有2種機型：
resources並放在單獨的目錄中，但在技術上他們是延伸CActiveRecord的模型。資源實例可以由REST客戶端發送的XML表示構造，並可以轉換爲XML表示。您可以定義一個基類AbstractResource，它將處理此問題，並在必要時覆蓋子資源中的構造/轉換方法。
一個資源有一個控制器。控制器通常有四個CRUD操作和可能的List操作。後者用於搜索操作。使用基於類的操作而不是內聯操作是一個好主意，因此您可以在不同的控制器中重用您的操作。例如，我所有的控制器都使用ListAction進行搜索。
我有基地控制器發送一切爲application/xml。它還處理HTTP狀態代碼和handles all errors。
所有來自客戶端的XML輸入都使用Relax NG schemes進行驗證。你需要json驗證器。
TDD岩石！我已經廣泛測試了幾乎所有東西。重構時會有很多幫助。使用TDD。爲所有模型，資源和應用程序組件編寫單元測試。此外，編寫功能測試更容易，因爲您沒有HTML/CSS /等。你只需發送HTTP請求並檢查返回的頭文件，代碼和內容。我使用php_curl擴展名，它工作得很好。由於您可能會執行PUT，DELETE和其他異常請求，因此您必須手動組合每個HTTP請求。在我的情況下，每個請求還需要簽名（這涉及計算校驗和，哈希等），所以幾乎不可能手動測試我的應用程序。
我也推薦這本優秀的書：RESTful Web Services。
嘿，謝謝你的回答！ 真的很豐富，我想我到目前爲止是沿着你概述的線路！ 我有一個接入點，ApiController它設置了很多的東西並限定actionAdd actionDelete actionUpdate列表和的actionView， 林路由等API /創建，圖案=>「API/
我正在通過與我的項目類似的練習。
我正在試圖決定讓所有工作都以優雅，可擴展的方式工作的最佳方式。 目前，這就是我：
/controllers/apiController
/controllers/api/v1/resourceaController <extends apiController>
/controllers/api/v1/resourcebController <extends apiController>
/controllers/api/v1/resourcecController <extends apiController>
我建立的解決方案具有的URL規則將用戶重定向直奔基於該方法在apiController適當的CRUD功能使用：
// REST API routes
array('api/list', 'pattern' => 'api/v<version:\d+>/<resource:\w+>', 'verb'=>'GET'),
array('api/create', 'pattern' => 'api/v<version:\d+>/<resource:\w+>', 'verb'=>'POST'),
array('api/view', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>', 'verb'=>'GET'),
array('api/update', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>', 'verb'=>'PUT'),
array('api/delete', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>', 'verb'=>'DELETE'),
array('api/list', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>', 'verb'=>'GET'),
array('api/create', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>', 'verb'=>'POST'),
array('api/view', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>/<association_id:\d+>', 'verb'=>'GET'),
array('api/update', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>/<association_id:\d+>', 'verb'=>'PUT'),
array('api/delete', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>/<association_id:\d+>', 'verb'=>'DELETE'),
功能接收到調用將嘗試基於$ _GET ['resource']實例化資源控制器並調用存儲在$ _GET ['association']中的函數。
我認爲這使得它的擴展性相當好，因爲我們可以有新版本的API出來，而且我們必須這樣做才能創建類似/ api/v2，/ api/v2並將所有必需的資源控制器在那裏。
我不完全確定您的意思是「服務器」的上下文，但是如果我不瞭解問題的其餘部分，我會使用與URL管理器結合使用的控制器來創建RESTful服務。 – ldg
嗨，是的，我認爲這就是我要採取的路線，我想當我開始規劃應用程序時，我一直在思考問題！即時通訊採取這種方式， 我有一個ApiController，擴展CController然後處理請求的控制器都擴展了api控制器 –