⑴ REST是什麼如何實現RESTful
REST (REpresentation State Transfer) 描述了一個架構樣式的網路系統，比如 web 應用程序。它首次出現在 2000 年 Roy Fielding 的博士論文中，他是 HTTP 規范的主要編寫者之一。REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。Web 應用程序最重要的 REST 原則是，客戶端和伺服器之間的交互在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的信息。如果伺服器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用伺服器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。在伺服器端，應用程序狀態和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程序對象、資料庫記錄、演算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的界面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態的引擎，資源表示通過超鏈接互聯。另一個重要的 REST 原則是分層系統，這表示組件無法了解它與之交互的中間層以外的組件。通過將系統知識限制在單個層，可以限制整個系統的復雜性，促進了底層的獨立性。當REST 架構的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和伺服器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和伺服器的實現。RESTful的實現：RESTful Web 服務與 RPC 樣式的 Web 服務了解了什麼是什麼是REST，我們再看看RESTful的實現。最近，使用 RPC 樣式架構構建的基於 SOAP 的 Web 服務成為實現 SOA 最常用的方法。RPC 樣式的 Web 服務客戶端將一個裝滿數據的信封（包括方法和參數信息）通過 HTTP 發送到伺服器。伺服器打開信封並使用傳入參數執行指定的方法。方法的結果打包到一個信封並作為響應發回客戶端。客戶端收到響應並打開信封。每個對象都有自己獨特的方法以及僅公開一個 URI 的 RPC 樣式 Web 服務，URI 表示單個端點。它忽略 HTTP 的大部分特性且僅支持 POST 方法。由於輕量級以及通過 HTTP 直接傳輸數據的特性，Web 服務的 RESTful 方法已經成為最常見的替代方法。可以使用各種語言（比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax]）實現客戶端。RESTful Web 服務通常可以通過自動客戶端或代表用戶的應用程序訪問。但是，這種服務的簡便性讓用戶能夠與之直接交互，使用它們的 Web 瀏覽器構建一個 GET URL 並讀取返回的內容。在REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。在RPC 樣式的架構中，關注點在於方法，而在 REST 樣式的架構中，關注點在於資源 —— 將使用標准方法檢索並操作信息片段（使用表示的形式）。資源表示形式在表示形式中使用超鏈接互聯。Leonard Richardson 和 Sam Ruby 在他們的著作 RESTful Web Services 中引入了術語 REST-RPC 混合架構。REST-RPC 混合 Web 服務不使用信封包裝方法、參數和數據，而是直接通過 HTTP 傳輸數據，這與 REST 樣式的 Web 服務是類似的。但是它不使用標準的 HTTP 方法操作資源。它在 HTTP 請求的 URI 部分存儲方法信息。好幾個知名的 Web 服務，比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用這種混合架構。RESTful的實現：RESTful Web 服務的 Java 框架有兩個 Java 框架可以幫助構建 RESTful Web 服務。erome Louvel 和 Dave Pawson 開發的 Restlet（見 參考資料）是輕量級的。它實現針對各種 RESTful 系統的資源、表示、連接器和媒體類型之類的概念，包括 Web 服務。在 Restlet 框架中，客戶端和伺服器都是組件。組件通過連接器互相通信。該框架最重要的類是抽象類 Uniform 及其具體的子類 Restlet，該類的子類是專用類，比如 Application、Filter、Finder、Router 和 Route。這些子類能夠一起處理驗證、過濾、安全、數據轉換以及將傳入請求路由到相應資源等操作。Resource 類生成客戶端的表示形式。JSR-311是 Sun Microsystems 的規范，可以為開發 RESTful Web 服務定義一組 Java API。Jersey是對 JSR-311 的參考實現。JSR-311 提供一組注釋，相關類和介面都可以用來將 Java 對象作為 Web 資源展示。該規范假定 HTTP 是底層網路協議。它使用注釋提供 URI 和相應資源類之間的清晰映射，以及 HTTP 方法與 Java 對象方法之間的映射。API 支持廣泛的 HTTP 實體內容類型，包括 HTML、XML、JSON、GIF、JPG 等。它還將提供所需的插件功能，以允許使用標准方法通過應用程序添加其他類型。RESTful的實現：構建 RESTful Web 服務的多層架構RESTful Web 服務和動態 Web 應用程序在許多方面都是類似的。有時它們提供相同或非常類似的數據和函數，盡管客戶端的種類不同。例如，在線電子商務分類網站為用戶提供一個瀏覽器界面，用於搜索、查看和訂購產品。如果還提供 Web 服務供公司、零售商甚至個人能夠自動訂購產品，它將非常有用。與大部分動態 Web 應用程序一樣，Web 服務可以從多層架構的關注點分離中受益。業務邏輯和數據可以由自動客戶端和 GUI 客戶端共享。惟一的不同點在於客戶端的本質和中間層的表示層。此外，從數據訪問中分離業務邏輯可實現資料庫獨立性，並為各種類型的數據存儲提供插件能力。圖1 展示了自動化客戶端，包括 Java 和各種語言編寫的腳本，這些語言包括 Python、Perl、Ruby、PHP 或命令行工具，比如 curl。在瀏覽器中運行且作為 RESTful Web 服務消費者運行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都屬於此列，因為它們都代表用戶以自動化樣式運行。自動化 Web 服務客戶端在 Web 層向 Resource Request Handler 發送 HTTP 響應。客戶端的無狀態請求在頭部包含方法信息，即 POST、GET、PUT 和 DELETE，這又將映射到 Resource Request Handler 中資源的相應操作。每個請求都包含所有必需的信息，包括 Resource Request Handler 用來處理請求的憑據。從Web 服務客戶端收到請求之後，Resource Request Handler 從業務邏輯層請求服務。Resource Request Handler 確定所有概念性的實體，系統將這些實體作為資源公開，並為每個資源分配一個惟一的 URI。但是，概念性的實體在該層是不存在的。它們存在於業務邏輯層。可以使用 Jersey 或其他框架（比如 Restlet）實現 Resource Request Handler，它應該是輕量級的，將大量職責工作委託給業務層。Ajax 和 RESTful Web 服務本質上是互為補充的。它們都可以利用大量 Web 技術和標准，比如 HTML、JavaScript、瀏覽器對象、XML/JSON 和 HTTP。當然也不需要購買、安裝或配置任何主要組件來支持 Ajax 前端和 RESTful Web 服務之間的交互。RESTful Web 服務為 Ajax 提供了非常簡單的 API 來處理伺服器上資源之間的交互。圖1 中的 Web 瀏覽器客戶端作為 GUI 的前端，使用表示層中的 Browser Request Handler 生成的 HTML 提供顯示功能。Browser Requester Handler 可以使用 MVC 模型（JSF、Struts 或 Spring 都是 Java 的例子）。它從瀏覽器接受請求，從業務邏輯層請求服務，生成表示並對瀏覽器做出響應。表示供用戶在瀏覽器中顯示使用。表示不僅包含內容，還包含顯示的屬性，比如 HTML 和 CSS。 業務規則可以集中到業務邏輯層，該層充當表示層和數據訪問層之間的數據交換的中間層。數據以域對象或值對象的形式提供給表示層。從業務邏輯層中解耦 Browser Request Handler 和 Resource Request Handler 有助於促進代碼重用，並能實現靈活和可擴展的架構。此外，由於將來可以使用新的 REST 和 MVC 框架，實現它們變得更加容易，無需重寫業務邏輯層。數據訪問層提供與數據存儲層的交互，可以使用 DAO 設計模式或者對象-關系映射解決方案（如 Hibernate、OJB 或 iBATIS）實現。作為替代方案，業務層和數據訪問層中的組件可以實現為 EJB 組件，並取得 EJB 容器的支持，該容器可以為組件生命周期提供便利，管理持久性、事務和資源配置。但是，這需要一個遵從 Java EE 的應用伺服器（比如 JBoss），並且可能無法處理 Tomcat。該層的作用在於針對不同的數據存儲技術，從業務邏輯中分離數據訪問代碼。數據訪問層還可以作為連接其他系統的集成點，可以成為其他 Web 服務的客戶端。數據存儲層包括資料庫系統、LDAP 伺服器、文件系統和企業信息系統（包括遺留系統、事務處理系統和企業資源規劃系統）。使用該架構，您可以開始看到 RESTful Web 服務的力量，它可以靈活地成為任何企業數據存儲的統一 API，從而向以用戶為中心的 Web 應用程序公開垂直數據，並自動化批量報告腳本。什麼是REST：結束語REST 描述了一個架構樣式的互聯系統（如 Web 應用程序）。REST 約束條件作為一個整體應用時，將生成一個簡單、可擴展、有效、安全、可靠的架構。由於它簡便、輕量級以及通過 HTTP 直接傳輸數據的特性，RESTful Web 服務成為基於 SOAP 服務的一個最有前途的替代方案。用於 web 服務和動態 Web 應用程序的多層架構可以實現可重用性、簡單性、可擴展性和組件可響應性的清晰分離。Ajax 和 RESTful Web 服務本質上是互為補充的。
⑵ ArcGIS Server REST 服務各類API的主要功能
這個問得比較大，REST是一個Web應用程序框架。ArcGIS REST API提供了簡單、開放的介面來訪問和使用ArcGIS Server發布的服務。使用ArcGIS REST API通過URL，可以獲取和操作每一個服務中的所有資源和操作。使用REST API就是通過URL來向GIS伺服器獲取資源的操作。
一般客戶端從伺服器端總是能得到一個資源的表現，在此一般分為兩種類型的資源：
Resources（資源，直接反應了服務本身的信息）
Operations（操作，根據服務本身的資源進行某些處理後得到的結果）
Catalog是整個REST APIURL分層等級的根。根下面是這個Server所發布的服務，一共有8種類型的服務：Map Service、Geocode Service、GP Service、Geometry Service、Image Service、Network Service、GeoData Service和Globe Service。每一種Service下面都有不同的操作和資源，而執行這些操作和獲取這些資源都是通過URL。
再具體的建議參考《ArcGIS Server REST API Help》。
⑶ spring mvc restful風格的api怎麼過濾相同路徑
Restful風格的API是一種軟體架構風格，設計風格而不是標准，只是提供了一組設計原則和約束條件。它主要用於客戶端和伺服器交互類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現緩存等機制。
在Restful風格中，用戶請求的url使用同一個url而用請求方式：get，post，delete，put...等方式對請求的處理方法進行區分，這樣可以在前後台分離式的開發中使得前端開發人員不會對請求的資源地址產生混淆和大量的檢查方法名的麻煩，形成一個統一的介面。
在Restful風格中，現有規定如下：
GET（SELECT）：從伺服器查詢，可以在伺服器通過請求的參數區分查詢的方式。
POST（CREATE）：在伺服器新建一個資源，調用insert操作。
PUT（UPDATE）：在伺服器更新資源，調用update操作。
PATCH（UPDATE）：在伺服器更新資源（客戶端提供改變的屬性）。(目前jdk7未實現，tomcat7也不行)。
DELETE（DELETE）：從伺服器刪除資源，調用delete語句。
了解這個風格定義以後，我們舉個例子：
如果當前url是 http://localhost:8080/User
那麼用戶只要請求這樣同一個URL就可以實現不同的增刪改查操作，例如
http://localhost:8080/User?_method=get&id=1001這樣就可以通過get請求獲取到資料庫 user 表裡面 id=1001 的用戶信息
http://localhost:8080/User?_method=post&id=1001&name=zhangsan這樣可以向資料庫 user 表裡面插入一條記錄
http://localhost:8080/User?_method=put&id=1001&name=lisi這樣可以將 user表裡面 id=1001 的用戶名改為lisi
http://localhost:8080/User?_method=delete&id=1001這樣用於將資料庫 user 表裡面的id=1001 的信息刪除
這樣定義的規范我們就可以稱之為restful風格的API介面，我們可以通過同一個url來實現各種操作。
⑷ 如何優雅的設計Restful API URL
一個好的RESTful API，應該具備以下特徵：
這個API應該是對瀏覽器友好的，能夠很好地融入Web，而不是與Web格格不入。
1.瀏覽器是最常見和最通用的REST客戶端。好的RESTful API應該能夠使用瀏覽器+HTML完成所有的測試（不需要使用編程語言）。這樣的API還可以很方便地使用各種自動化的Web功能測試、性能測試工具來做測試。Web前端應用（基於瀏覽器的RIA應用、移動App等等）也可以很方便地將多個RESTful API的功能組合起來，建造Mashup類的應用。
這個API中所包含的資源和對於資源的操作，應該是直觀和容易理解的，並且符合HTTP協議的要求。
REST開發又被稱作「面向資源的開發」，這說明對於資源的抽象，是設計RESTful API的核心內容。RESTful API建模的過程與面向對象建模類似，是以名詞為核心的。這些名詞就是資源，任何可命名的抽象概念都可以定義為一個資源。而HTTP協議並不是一種傳輸協議，它實際提供了一個操作資源的統一介面。對於資源的任何操作，都應該映射到HTTP的幾個有限的方法（常用的有GET/POST/PUT/DELETE四個方法，還有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTful API建模的過程，可以看作是具有統一介面約束的面向對象建模過程。
按照HTTP協議的規定，GET方法是安全且冪等的，POST方法是既不安全也不冪等的（可以用來作為所有寫操作的通配方法），PUT、DELETE方法都是不安全但冪等的。將對資源的操作合理映射到這四個方法上面，既不過度使用某個方法（例如過度使用GET方法或POST方法），也不添加過多的操作以至於HTTP的四個方法不夠用。
2.如果發現資源上的操作過多，以至於HTTP的方法不夠用，應該考慮設計出更多的資源。設計出更多資源（以及相應的URI）對於RESTful API來說並沒有什麼害處。
這個API應該是松耦合的。
RESTful API的設計包括了三個循序漸進、由低到高的層次：資源抽象、統一介面、超文本驅動。正是這三個層次確保了RESTful API的松耦合性。
3.當設計面向互聯網的API時，松耦合變成了一種「必須有」的強需求。緊耦合的API非常脆弱，一旦公布出去，伺服器端和客戶端都無法持續進化。尤其是伺服器端，公布出去的介面根本不敢改，改了之後，幾乎所有客戶端應用立即無法正常工作。REST這種架構風格就是緊耦合API的解毒劑，這個話題可以談的很深，這里就不展開了。感興趣的讀者可以參考《REST實戰》。
這個API中所使用的表述格式應該是常見的通用格式
在RESTful API中，對於資源的操作，是通過在伺服器端-客戶端之間傳遞資源的表述來間接完成的。資源的表述可以有很多種格式，並且在響應和請求中的資源表述格式也會有所不同。GET/POST響應中的資源表述格式，常見的有HTML、XML、JSON；POST/PUT請求中的資源表述格式，常見的有標準的HTML表單參數、XML、JSON。
4.這些常見表述格式，處理起來非常容易，有大量的框架和庫提供支持。所以除非有很合理的要求，通常不需要使用自定義的私有格式。
使用HTTP響應狀態代碼來表達各種出錯情況
HTTP響應狀態代碼，是HTTP協議這個統一介面中用來表達出錯情況的標准機制。響應狀態代碼分成兩部分：status code和reason phase。兩部分都是可定製的，也可以使用標準的status code，只定製reason phase。
5.如果一個所謂的「RESTful API」對於任何請求都返回200 OK響應，在響應的消息體中返回出錯情況信息，這種做法顯然不符合「確保操作語義的可見性」這個REST架構風格的基本要求。
這個API應該對於HTTP緩存是友好的
6.充分利用好HTTP緩存是RESTful API可伸縮性的根本。HTTP協議是一個分層的架構，從兩端的user agent到origin server之間，可以插入很多中間組件。而在整個HTTP通信鏈條的很多位置，都可以設置緩存。HTTP協議內建有很好的緩存機制，可以分成過期模型和驗證模型兩套緩存機制。如果API設計者完全沒有考慮過如何利用HTTP緩存，那麼這個API的可伸縮性會有很多問題。
⑸ 如何在REST API中使用查閱項的值作為過濾條件
由於REST可以降低開發的復雜度，提高系統的可伸縮性，增強系統的可擴展性，簡化應用系統之間的集成，因而得到了廣大開發人員的喜愛，同時得到了業界廣泛的支持。
⑹ Spring中攔截/和攔截/*的區別
一、我們都知道在基於Spring的Application中，需要在web.xml中增加下面類似的配置信息：
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<!-- Spring MVC Servlet -->
<servlet>
<servlet-name>servletName</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>servletName</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
此處需要特別強調的是 <url-pattern>/</url-pattern>使用的是/，而不是/*,如果使用/*,那麼請求時可以通過DispatcherServlet轉發到相應的Action或者Controller中的，但是返回的內容，如返回的jsp還會再次被攔截，這樣導致404錯誤，即訪問不到jsp。所以如果以後發現總是有404錯誤的時候，別忘了check一下 <url-pattern>/</url-pattern>的配置是否是/*.
二、其實Spring 的Servlet攔截器匹配規則（即 <url-pattern>...</url-pattern> ）都可以自己定義，例：當映射為@RequestMapping("/user/add")時
1、攔截*.do、*.htm， 例如：/user/add.do
這是最傳統的方式，最簡單也最實用。不會導致靜態文件（jpg,js,css）被攔截。
2、攔截/，例如：/user/add
可以實現現在很流行的REST風格。很多互聯網類型的應用很喜歡這種風格的URL。
弊端：會導致靜態文件（jpg,js,css）被攔截後不能正常顯示。想實現REST風格，事情就是麻煩一些。後面有解決辦法還算簡單。
3、攔截/*，這是一個錯誤的方式，請求可以走到Action中，但轉到jsp時再次被攔截，不能訪問到jsp。
三、如何訪問到靜態的文件，如jpg,js,css?
如果你的DispatcherServlet攔截"*.do"這樣的有後綴的URL，就不存在訪問不到靜態資源的問題。
如果你的DispatcherServlet攔截"/"，為了實現REST風格，攔截了所有的請求，那麼同時對*.js,*.jpg等靜態文件的訪問也就被攔截了。
我們要解決這個問題。
目的：可以正常訪問靜態文件，不可以找不到靜態文件報404。
方案一：激活Tomcat的defaultServlet來處理靜態文件
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.jpg</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.js</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.css</url-pattern>
</servlet-mapping>
特點：1. 要配置多個，每種文件配置一個。
2. 要寫在DispatcherServlet的前面， 讓 defaultServlet先攔截請求，這樣請求就不會進入Spring了。
3. 高性能。
備註：
Tomcat, Jetty, JBoss, and GlassFish 自帶的默認Servlet的名字 -- "default"
Google App Engine 自帶的 默認Servlet的名字 -- "_ah_default"
Resin 自帶的 默認Servlet的名字 -- "resin-file"
WebLogic 自帶的 默認Servlet的名字 -- "FileServlet"
WebSphere 自帶的 默認Servlet的名字 -- "SimpleFileServlet"
方案二： 在spring3.0.4以後版本提供了mvc:resources ， 使用方法：
<!-- 對靜態資源文件的訪問 -->
<mvc:resources mapping="/images/**" location="/images/" />
images/**映射到 ResourceHttpRequestHandler進行處理，location指定靜態資源的位置.可以是web application根目錄下、jar包裡面，這樣可以把靜態資源壓縮到jar包中。cache-period 可以使得靜態資源進行web cache
如果出現下面的錯誤，可能是沒有配置<mvc:annotation-driven />的原因。
報錯WARNING: No mapping found for HTTP request with URI [/mvc/user/findUser/lisi/770] in DispatcherServlet with name 'springMVC'使用<mvc:resources/>元素,把mapping的URI注冊到SimpleUrlHandlerMapping的urlMap中,
key為mapping的URI pattern值,而value為ResourceHttpRequestHandler,
這樣就巧妙的把對靜態資源的訪問由HandlerMapping轉到ResourceHttpRequestHandler處理並返回,所以就支持classpath目錄,jar包內靜態資源的訪問.
另外需要注意的一點是,不要對SimpleUrlHandlerMapping設置defaultHandler.因為對static uri的defaultHandler就是ResourceHttpRequestHandler,
否則無法處理static resources request.
方案三 ，使用<mvc:default-servlet-handler/>
<mvc:default-servlet-handler/>
會把"/**" url,注冊到SimpleUrlHandlerMapping的urlMap中,把對靜態資源的訪問由HandlerMapping轉到 org.springframework.web.servlet.resource. 處理並返回.
使用就是各個Servlet容器自己的默認Servlet.
補充說明：多個HandlerMapping的執行順序問題：
的order屬性值是：0
< mvc:resources/ > 自動注冊的 SimpleUrlHandlerMapping 的order屬性值是： 2147483646
<mvc:default-servlet-handler/>自動注冊 的SimpleUrlHandlerMapping 的order屬性值是： 2147483647
spring會先執行order值比較小的。當訪問一個a.jpg圖片文件時，先通過 來找處理器，一定是找不到的，因為我們沒有叫a.jpg的Action。然後再按order值升序找，由於最後一個 SimpleUrlHandlerMapping 是匹配 "/**"的，所以一定會匹配上，就可以響應圖片。 訪問一個圖片，還要走層層匹配。不知性能如何？
最後再說明一下，方案二、方案三 在訪問靜態資源時，如果有匹配的(近似)總攔截器，就會走攔截器。如果你在攔截中實現許可權檢查，要注意過濾這些對靜態文件的請求。
如何你的DispatcherServlet攔截 *.do這樣的URL後綴，就不存上述問題了。還是有後綴方便。
⑺ 在REST API上實現防抵賴、防篡改驗證的簡便方法
開放basic auth並且map到一個現有的資料庫用戶表或者一個xml文件就可以了。
防篡改可以加一個ACL 控制
⑻ 如何更好地設計REST API
由於REST可以降低開發的復雜度，提高系統的可伸縮性，增強系統的可擴展性，簡化應用系統之間的集成，因而得到了廣大開發人員的喜愛，同時得到了業界廣泛的支持。比如IBM，Google等公司的很多產品都提供了REST API給開發人員；與此同時，大量的開源項目和雲計算服務都提供了REST API介面。
而在最近，一些新產品的開發甚至已經幾乎完全拋棄了傳統的類似JSP的技術， 轉而大量使用REST風格的構架設計， 即在伺服器端所有商業邏輯都以REST API的方式暴露給客戶端， 所有瀏覽器用戶界面使用widget、Ajax、HTML5 等技術，用HTTP的方式與後台直接交互。
那麼， 在REST API爆炸式增長的今天， 我們應該如何更好的設計我們的介面， 來提高我們的API的可用性，易用性，可維護性與可擴展性呢？本文將從以下方面與您探討REST API設計方面的最佳實踐：
如何規劃資源標識結構與URI模式
如何根據應用場景提供內容協商
如何正確的使用HTTP響應代碼
如何處理緩存和並發請求
如何利用數據冗餘和鏈接元素
先決條件
如果您具有如下知識與經驗，將有助於您閱讀和理解本文章的內容 。
REST相關的基本知識；
HTTP協議的基本知識；
一定的Web開發經驗。
REST簡介
REST是英文Representational State Transfer的縮寫，是近年來迅速興起的，一種基於HTTP、URI以及XML這些現有協議與標準的，針對網路應用的設計和開發方式。它可以降低開發的復雜度，提高系統的可伸縮性。
REST的核心是可編輯的資源及其集合，用符合Atom文檔標準的Feed和Entry表示。每個資源或者集合有一個惟一的URI。系統以資源為中心，構建並提供一系列的Web服務。REST的基本概念和原則包括：系統上的所有事物都被抽象為資源；每個資源對應唯一的資源標識；對資源的操作不會改變資源標識本身；所有的操作都是無狀態的；等等。
在REST中，開發人員顯式地使用HTTP方法，對系統資源進行創建、讀取、更新和刪除的操作：
使用POST方法在伺服器上創建資源
使用GET方法從伺服器檢索某個資源或者資源集合
使用PUT方法對伺服器的現有資源進行更新
使用DELETE方法刪除伺服器的某個資源
圖 1. 用 HTTP 方法操作相冊系統資源的簡單範例
更好的規劃你的資源標識結構與URI模式
REST 中，最基本的莫過於資源標識結構和URI模式了。更好的規劃他們，是我們的API設計取得成功的最關鍵的一步。
首先，我們來看看基本資源類型
上文中提到，在REST構架的設計中，系統中的所有事物都被抽象為資源。
在一個文檔系統中，文檔、目錄、注釋、草稿等等，是組成系統的資源。
在一個銀行系統中，客戶信息、理財產品、利率信息、網點信息等等，是組成系統的資源。
在一個航空客票系統中，旅客信息、機票訂單、航班信息、機場信息等等，是組成系統的資源。
這些資源，通常在系統中以「Entry」的形式出現。下面的代碼樣例向您展示了一個常見的「Entry」資源。
清單 1. 一個簡單的Entry資源樣例
以下是引用片段：
REST API 請求：
GET http://example.com/航班信息/CA827/entry
<entry>
<id> CA827 </id>
<link href="航班信息 /CA827/entry" rel="self"/>
<title type="text">CA827 </title>
<published>2010-08-24T02:35:40.937Z </published>
<updated>2010-08-24T02:35:40.937Z </updated>
<ca:from>Beijing </ca:from>
<ca:to>Changsha </ca:to>
<ca:time>09:30:00 </ca:time>
<ca:aircraft>AB330 </ca:aircraft>
<summary type="text"/>
</entry>
我們會注意到，這些資源，在描述了某種事物的同時，還有可能存在一定的層次結構關系。比如，文檔從屬於某個目錄，注釋從屬於文檔；旅客信息可以從屬於機票訂單，也可以從屬於某個航班。
當我們的資源有這種層次關系的時候，我們不妨在URI模式的設計中，用復合的URI來幫助開發者更好的理解和設計資源。
比如， 針對一個文檔的評論， 他的URI模式可以設計成如下：/文件夾/[文件夾名]/文件/[文件名]/評論/[ 評論唯一標示 ]。 這樣，在構造和解析URI的過程中， 可以幫助開發者更好的理解系統，設計程序。
其次，我們來看看集合資源類型
資源，除了作為獨立個體可以被訪問，還可以由多個個體組合成一個集合，在系統中，通常以「feed」的形式存在。資源的集合， 可以是處於相同層次上，有相同從屬關系的一組資源，比如一個文件夾下的所有文件； 也可以是根據某種條件查詢出來的查詢結果的資源集合，比如所有30歲以上40歲以下，擁有100萬資產以上客戶的名單。
下面，我們來討論一下設計集合類型資源的REST API時需要考慮的問題。
使用過濾條件來幫助用戶更准確地獲取數據
我們要返回的資源集合，無論是否有相同從屬關系，大部分時候都需要進行必要的過濾，提供足夠的過濾參數，查詢參數， 能夠幫助開發者高效的，准確地獲取所需要的數據。 在伺服器端過濾數據通常比客戶端高效，並且減少了不必要的數據傳輸，可以大大減少網路開銷，提高執行效率。
最常見的過濾條件，是通過URL參數實現，比如/環境工程系/學生? 籍貫=北京&性別=女。
很多時候，我們需要制定更加復雜的過濾條件，那麼我們可以有兩種選擇：
首先，我們可以使用正則表達式或者伺服器可以理解的語法，比如/環境工程系/學生?filter=age between (15, 18)
其次，我們還可以使用POST方法，攜帶一個文件來描述復雜的查詢條件，文件的格式與語法通常需要在伺服器端有相應的設計與定義。不過通常POST方法沒有緩存機制，因此不是查詢數據的首選。
使用排序來幫助客戶端更好的展現數據
雖然進行客戶端排序對於開發者來說是件輕而易舉的事情，但是直接得到已經排序的返回結果，仍然是大部分開發者所期望的。尤其是很多時候，我們在瀏覽器，使用 Widget 展示結果，不適宜在客戶端存儲大量數據進行內存排序。
排序， 通常有2個參數，一個是用來排序的欄位，一個是排序的升序降續方式。比如我們可以用支持這樣的參數組合的手段，提供基本的排序能力：?sortOrder=asc&sortField=age
使用分頁來幫助客戶端處理大量數據
由於返回的結果可能有幾百幾千條記錄，將這些記錄一次性的返回給客戶端是不現實的，巨大的網路流量開銷和客戶端數據區的內存開銷，都是我們在應用開發的時候不希望看到的，因此，如果你的集合資源有可能有大量的數據返回，請務必提供分頁的功能支持。
我們通常用一個以上參數來制定一個返回結果的區域，比較常見的有下面兩種：
一種常見於用固定行數的表格來展示數據，用當前處於第幾頁和每頁返回多少行數據來確定需要的數據， 比如/所有學生?page=5&pagesize=50
另外一種常見於用更加靈活的界面展示數據，用從第幾行開始，一共返回多少行數據來確定需要的數據， 比如/所有學生?startIndex=27&count=22
下面是一個來自IBM developerWorks的API樣例，嘗試請求該API，你可以看到該集合很好的支持了結果的分頁與排序。同時我們從返回的信息中可以看到，每個文檔Entry的URI都按照/社區庫/[社區庫ID]/文檔/[文檔ID]的復合URI的模式設計的。
清單 2. IBM developerWorks的某個社區文件庫的集合資源的API
以下是引用片段：
REST API 請求：
GET https://www.ibm.com/developerworks/mydeveloperworks
/files/form/anonymous/api/communitylibrary
/0a7c97bb-6cf9-4ddb-a918-80994e7b444d/feed?
pageSize=5&page=1&sK=modified&sO=dsc
最後，我們來討論一些特殊資源類型
理想的REST世界，一切事物都抽象為資源，一切操作都抽象為增刪改查。然而，所有事物與操作都可以很容易的按照這個規則作抽象嗎？讓我們看看這個例子：
檢入和檢出一個文檔----這個時候，我們要處理的資源是一個文檔，然而增刪改查似乎都無法與「檢入檢出」這個動作進行對應。當然，我們可以在文檔資源中，設計一個檢入檢出狀態的元素，通過編輯文檔資源來實現。但是，這種設計從自然語義上看，並不是很貼切；並且增加了資源編輯操作的復雜度。
如果我們來定義一個新的集合----「我檢出的文檔」，用創建一個集合資源來對應檢出（創建一個文檔鎖），用刪除一個集合資源來對應檢入（刪除一個文檔鎖）， 是不是邏輯上可以變得更加清楚？
在REST這個以名詞為核心的構架結構中，當你遇到一些動詞特性比較強的操作，而又很難用原始資源的增刪改查來匹配的時候，不妨換個思路， 通過引入新的邏輯資源集合的方式， 來進行API的設計與規劃。
理解和使用內容協商
我們的開發者在發送一個REST API請求的同時，根據應用場景，針對相同的資源，可能會期待不同的返回形式。
比如，我希望根據用戶客戶端語言，同一個資源的內容可以返回不同的語言。又比如，當我使用Java編程的時候，我希望得到ATOM格式的返回結果，而當我使用JavaScript編程的時候，我希望得到Json格式的返回結果。
因此，我們在設計REST API的時候，應該提供完備的內容協商能力。
使用URL參數進行內容協商
最容易想到的自然是通過URL參數進行控制，我們經常看到形如/航班號/entry? format=JSON這樣的URL。這種方式的優勢就是簡單靈活， 你可以通過任何 URL 參數來組合你的輸出格式。
下面是一個來自IBM developerWorks的API樣例，嘗試請求該API，你可以看到該集合是如何支持不同的輸出格式請求的。
清單 3. IBM developerWorks的文件服務標簽雲的API
以下是引用片段：
REST API請求，要求返回XML格式數據：
GET https://www.ibm.com/developerworks/mydeveloperworks
/files/form/anonymous/api/tags/feed?format=xml
&scope=document&pageSize=30&sK=cloud&sO=dsc
REST API請求，要求返回JSON格式數據：
GET https://www.ibm.com/developerworks/mydeveloperworks
/files/form/anonymous/api/tags/feed?format=json
&scope=document&pageSize=30&sK=cloud&sO=dsc
使用Accept頭進行內容協商
使用URL參數，簡單靈活，但是也由此帶來了設計上的隨意和不標准。並且，過多的參數會導致URL的可讀性變差，更有甚者，可能會導致URL過長，超出規范，API請求無法執行。
更為標準的內容協商方式是使用HTTP頭。我們通常使用Accept來設置我們接受的返回結果的內容格式，用Accept-Charset來設置字元集，用Accept-Encoding來設置數據傳輸格式，用Accept-Language來設置語言。
使用URI模式進行內容協商
還有一種模式，就是將協商設置直接作為URI的一部分，將不同的返回視為不同的資源，比如/航班號/json來返回JSON格式的結果，用/航班號/atom來返回ATOM格式的結果。
正確的使用HTTP響應代碼
作為API的設計者，正確的將API執行結果和失敗原因用清晰簡潔的方式傳達給客戶程序是十分關鍵的一步。 我們確實可以在HTTP的相應內容中描述是否成功，如果出錯是因為什麼， 然而， 這就意味著用戶需要進行內容解析，才知道執行結果和錯誤原因。因此，HTTP響應代碼可以保證客戶端在第一時間用最高效的方式獲知API運行結果，並採取相應動作。
轉載，僅供參考，祝你愉快，滿意請採納。
⑼ 如何設計RESTful的API許可權
RESTful的授權依靠框架就能解決 比如Jersey Spring，以及servlet容器等都提供授權機制；RESTful難的是認證，token一旦被劫持，授權就沒有意義了。
⑽ RESTful API 怎麼實現用戶許可權控制
本文是基於RESTful描述的，需要你對這個有初步的了解。
RESTful是什麼？
Representational State Transfer，簡稱REST，是Roy Fielding博士在2000年他的博士論文中提出來的一種軟體架構風格。
REST比較重要的點是資源和狀態轉換，
所謂"資源"，就是網路上的一個實體，或者說是網路上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。
而"狀態轉換"，則是把對應的HTTP協議裡面，四個表示操作方式的動詞分別對應四種基本操作：
1. GET，用來瀏覽(browse)資源
2. POST，用來新建(create)資源
3. PUT，用來更新(update)資源
4. DELETE，用來刪除(delete)資源。
資源的分類及操作
清楚了資源的概念，然後再來對資源進行一下分類，我把資源分為下面三類：
1. 私人資源 (Personal Source)
2. 角色資源 (Roles Source)
3. 公共資源 (Public Source)
"私人資源"：是屬於某一個用戶所有的資源，只有用戶本人才能操作，其他用戶不能操作。例如用戶的個人信息、訂單、收貨地址等等。
"角色資源"：與私人資源不同，角色資源范疇更大，一個角色可以對應多個人，也就是一群人。如果給某角色分配了許可權，那麼只有身為該角色的用戶才能擁有這些許可權。例如系統資源只能夠管理員操作，一般用戶不能操作。
"公共資源"：所有人無論角色都能夠訪問並操作的資源。
而對資源的操作，無非就是分為四種：
1. 瀏覽 (browse)
2. 新增 (create)
3. 更新 (update)
4. 刪除 (delete)
角色、用戶、許可權之間的關系
角色和用戶的概念，自不用多說，大家都懂，但是許可權的概念需要提一提。
"許可權"，就是資源與操作的一套組合，例如"增加用戶"是一種許可權，"刪除用戶"是一種許可權，所以對於一種資源所對應的許可權有且只有四種。
角色與用戶的關系：一個角色對應一群用戶，一個用戶也可以扮演多個角色，所以它們是多對多的關系。
角色與許可權的關系：一個角色擁有一堆許可權，一個許可權卻只能屬於一個角色，所以它們是一(角色)對多(許可權)的關系
許可權與用戶的關系：由於一個用戶可以扮演多個角色，一個角色擁有多個許可權，所以用戶與許可權是間接的多對多關系。
需要注意兩種特別情況：
1. 私人資源與用戶的關系，一種私人資源對應的四種許可權只能屬於一個用戶，所以這種情況下，用戶和許可權是一(用戶)對多(許可權)的關系。
2. 超級管理員的角色，這個角色是神一般的存在，能無視一切阻礙，對所有資源擁有絕對許可權，甭管你是私人資源還是角色資源。
資料庫表的設計
角色、用戶、許可權的模型應該怎麼樣設計，才能滿足它們之間的關系？
對上圖的一些關鍵欄位進行說明：
Source
name: 資源的名稱，也就是其他模型的名稱，例如：user、role等等。
identity: 資源的唯一標識，可以像uuid，shortid這些字元串，也可以是model的名稱。
permissions : 一種資源對應有四種許可權，分別對這種資源的browse、create、update、delete
Permission
source : 該許可權對應的資源，也就是Source的某一條記錄的唯一標識
action ：對應資源的操作，只能是browse、create、update、delete四個之一
relation：用來標記該許可權是屬於私人的，還是角色的，用於OwnerPolicy檢測
roles: 擁有該許可權的角色
Role
users : 角色所對應的用戶群，一個角色可以對應多個用戶
permissions: 許可權列表，一個角色擁有多項權利
User
createBy : 該記錄的擁有者，在user標里，一般等於該記錄的唯一標識，這一屬性用於OwnerPolicy的檢測，其他私有資源的模型設計，也需要加上這一欄位來標識資源的擁有者。
roles : 用戶所擁有的角色
策略/過濾器
在sails下稱為策略(Policy)，在java
SSH下稱為過濾器(Filter)，無論名稱如何，他們工作原理是大同小異的，主要是在一條HTTP請求訪問一個Controller下的action
之前進行檢測。所以在這一層，我們可以自定義一些策略/過濾器來實現許可權控制。
為行文方便，下面姑且允許我使用策略這一詞。
*策略 (Policy) *
下面排版順序對應Policy的運行順序
SessionAuthPolicy：
檢測用戶是否已經登錄，用戶登錄是進行下面檢測的前提。
SourcePolicy：
檢測訪問的資源是否存在，主要檢測Source表的記錄
PermissionPolicy：
檢測該用戶所屬的角色，是否有對所訪問資源進行對應操作的許可權。
OwnerPolicy：
如果所訪問的資源屬於私人資源，則檢測當前用戶是否該資源的擁有者。
如果通過所有policy的檢測，則把請求轉發到目標action。