當我沒有完全接受REST時，我應該使用Web API

我正在開發在桌面瀏覽器，平板電腦瀏覽器和電話瀏覽器中運行的單頁應用程序。我只從我的後端返回JSON，它是ASP.NET MVC或Web API。當我沒有完全接受REST時，我應該使用Web API

當我想到Web API或閱讀它時，我總是聽到REST/RESTfull這個詞。獨立於什麼剩下的就是我喜歡的Web API的一些功能，我還沒有在MVC（默認情況下，但也許可以以某種方式實現，但我不希望額外的努力...）

返回的HTTPStatus碼200一樣對於創建資源時的GET或201。我的單頁應用程序知道並對此代碼作出反應。
直接在控制器中返回DTO並將c＃類自動序列化爲json。有了MVC，這不是一蹴而就的。不處理ActionResults。
Web API是關於'酷'URL /路由的非常多的設計我也會在我的客戶端有深度/複雜的路由。
我的Web API端點都只是「AJAX回調」我並不需要休息之類的東西包括在每一個檢索的ressource等一self.link ...

當然我沒有創建/修改一個ressources獲取請求。但是我在做MVC時已經習慣了這種風格。所以我喜歡並且會做很多REST風格，但不是因爲REST本身而是它的慣例。

我應該真的設計出優秀的restfull API來使用Web API嗎？我不知道什麼是微軟關於Web API的推薦，或者他們真的有關於它的指導...

2013-12-14 Elisabeth

書中的REST似乎適合經典的CRUD風格的應用情況最好。我發現在編寫報告或BI類型應用程序時，完全遵循REST規則並不適合我。例如，我使用請求主體中的PUT來處理複雜的過濾和排序參數。一般來說，你不需要完全遵循規則，特別是在CRUD世界之外，但是不要太偏離軌道。 – jfrankcarr

根據我的經驗，Web API經常是一個很好的幫助，而且很少是一個障礙。如果你這樣做「他們的方式」，它可以節省你很多關於序列化/路由/綁定的難題。如果你不想這樣做「他們的方式」，你不必這樣做。您可以擴展路由引擎。你可以實現你自己的序列化。如果您認爲合適，您可以返回原始JSON。 Web API中的任何內容都不會迫使您將REST概念應用於T（相信我已經看到了這一點）。我以前從沒有聽說過任何使用過它的人的投訴 - 我建議你試一試，看看它真的有多遠。

來源

2013-12-14 09:34:13

根本不需要REST來使用Web API。實際上，打開和使用會話管理也很容易。

事實上，雖然RESTful方法有一些真正的優勢，但我不會推薦使用100％RESTful。如果不使用第三方身份驗證提供程序，則無法使其充分安全。我們構建了一個完整的RESTful原型，並探索了許多不同的機制來保護網站。但最終，每個人都有一個或另一個漏洞（這有助於在員工身上擁有CISSP）。所以我與諾頓的一位頂級安全專家交談，他同意，是的，總有一種方法可以利用完全REST風格的獨立應用程序。賽門鐵克顯然正在構建一個能夠解決這個問題的「包裝器」技術，但與第三方認證提供商一起使用或者使用會話cookie返回基於MS的安全性更容易。

來源

2015-02-07 19:04:30

當我沒有完全接受REST時，我應該使用Web API

回答

相關問題