rest伺服器

1、如何構建REST風格的WEB地圖服務

REST英文全稱為Representational State Transfer（表述性狀態遷移），是2000年Roy Thomas Fielding博士在他的畢業論文中首次提出的概念，國內一幫精英已經把Fielding的論文翻成了中文，但是看完論文還是很難搞清REST到底是什麼。Leonard Richardson與Sam Ruby的新書《RESTful Web Services》對REST作了簡單而具體的詮釋，提出了面向資源架構（The Resource-Oriented Architecture）的設計方法。根據對書中內容的理解，我這里作一簡單的總結，不一定對，僅供參考。
1 什麼是REST
REST是一組設計原則，或說是一種風格，不是架構，Fielding在他的論文中表示符合REST原則的web服務將在可見性、可靠性與可伸縮性等方面獲益，而且符合萬維網創建的初衷。
Google map（http://maps.google.com/）就是REST風格的web服務一例，當游標熱點移動時，左下角隨之變化的URI可以看出它是根據URI在提供相應的web服務。
REST是一組廣義的設計原則，REST本身並沒有與Web、HTTP或URI綁定，REST設計原則包括客戶-伺服器、無狀態、緩存、統一介面、分層系統等。既然原則中要求無狀態，又何來表述性狀態呢？REST原則的無狀態指伺服器端不保存客戶應用狀態，連接→請求→響應→斷開，客戶的上一次請求與下一個請求沒有關系（這其實是HTTP的特徵）。伺服器端響應客戶請求返回資源的表述及相關鏈接（想像一下google返回的頁面），該表述的本身就是客戶的當前狀態，客戶按照表述中提供的鏈接選擇下一個表述，遷移到下一個狀態。這是我從字面上對REST的解釋，也就是伺服器通過表述為狀態遷移提供指導，而狀態的遷移權掌控在用戶手裡，客戶根據自己的需要選擇鏈接，由當前狀態遷移到下一個狀態。這個解釋很膚淺，下面的面向資源架構從根本上對REST作了技術上的詮釋。
2 面向資源架構
面向資源架構是一種REST風格的架構，它以資源為研究對象，通過劃分資源、定義資源，然後用超媒體將資源串起來，提供客戶所需求的服務。面向資源架構包括四個組成元素，具有四個屬性。四個組成元素是：資源、資源名、資源表述和鏈接。四個屬性是：可定址、無狀態、連通和統一介面。
2.1 四個元素
（1） 資源
就象面向對象設計取決於問題域對象劃分一樣，面向資源設計的首要任務就是劃分資源，實際上面向資源是極端的面向對象，因為REST中規定了統一介面約束，要求對資源的操作必須是可見的（如HTTP中標準的GET、PUT、DELETE、POST，帶暗箱操作的POST不算），因此資源的操作方法是不能自行定義的。
在面向資源設計中的資源可以是任何具有超文本鏈接價值的東西，資源可以是數據資源，也可以是物理對象，物理對象本身不能在網上傳輸，但物理對象的元數據可以。當統一介面方法不能滿足需求時，可以通過設計資源將操作名詞化，例如你「訂閱」某個欄目，統一介面中沒有「訂閱」操作，也不允許你自行定義「訂閱」操作，怎麼辦呢？你可以將「訂閱」設計為資源「訂閱關系」，「訂閱關系」就可以用統一介面中的方法，如GET、PUT、DELETE進行操作了。同樣，對於需要非同步完成的操作，也可以通過資源將非同步操作劃分為多個同步操作來完成。總之，資源可以是任何東西，遇到困惑時可以設法通過資源來解決。
（2） 資源名
資源能成為資源的必要條件是：每個資源必須用URI唯一標識。這符合Tim Berners-Lee公理：Web上每一個資源由URL唯一確定。超文本系統、HTTP 和Internet分層協議之間是不能交流的，URI把所有這些協議集成到了web中。資源用URI命名，資源通過URI定位，URI中不僅包含資源的地址，還包含對資源的操作指令，伺服器端根據URI中的指令確定客戶請求的處理方式。因此，這里的URI不是單純的網址。
（3） 資源表述
資源是表述的數據源，表述是資源的當前狀態（應客戶請求返回的網頁），對REST風格的服務來說表述是超媒體，表述中不僅包含著當前資源的信息，還包含了相關資源的鏈接。
因此，表述呈現了資源的當前狀態，也鏈接著資源的其它狀態。表述具體涉及資源的數據及數據格式。可用於表述的超媒體格式有多種，如： 應用/XHTML+XML、應用/ATOM+XML、圖像/SVG+XML、應用/JSON、應用/WADL+XML。《RESTful Web Services》書中對WADL（Web Application Description Language，https://wadl.dev.java.net）較為推崇，WADL是用於描述HTTP資源特徵的XML格式定義（詞彙表），書中認為WADL剝離了HTTP請求和響應（表述的建造與解析）的細節，支持URI模板及HTTP統一介面，可以特定符合XML Schema定義的XML表述格式，可簡化web服務的客戶端編程，與其它超媒體格式相比，WADL有其獨特的優點。
（4） 資源鏈接
資源不是孤立的，是可以連通的，資源通過Link或Form鏈接，Link與Form本身就是資源表述的一種，因此說表述是超媒體。
2.2 四個屬性
（1） 可定址
每個資源由唯一的URI標識，使資源可定位，也因此使緩存成為可能。
（2） 無狀態
客戶請求與服務響應通過HTTP 通信，HTTP本身是無狀態的，HTTP請求在完全封閉的過程中完成，請求中包含了伺服器完成請求所必需的全部信息，請求與請求之間沒有關聯。這樣，伺服器端無需等待、無需追蹤，它只需要關心客戶發送請求時的應用狀態就足夠了。伺服器端的服務之間也不需要分工協作，服務擴展只是將服務插入負載均衡器就行了，這樣就增強了服務的伸縮性能。
REST 中的無狀態是指僅有一種狀態，該狀態不在伺服器端而在客戶端。其實，從資源角度來說，伺服器端也有狀態，那就是資源狀態。伺服器應客戶請求返回資源的表述，資源通過HTTP由資源狀態遷移到客戶應用狀態；客戶向伺服器上傳資源表述（例如Amazon的S3服務），客戶應用狀態通過HTTP遷移到伺服器變成了資源狀態，這是不是應該是REST的真正含義？
（3） 連通
資源應該以某種方式連通，也就是資源是鏈接的，不需要用戶在瀏覽器中鍵入URI執行跳轉。Link或Form鏈接是資源連通的超媒體。
（4） 統一介面
面向資源架構利用了HTTP的統一介面，HTTP統一介面提供了四種基本操作方法GET、PUT、DELETE和POST，面向資源架構要求所有服務按HTTP標准方式使用GET、PUT、DELETE和POST，這樣安全性好，沒有副作用產生，其次響應結果具冪等性（數學上術語），即同一請求返回的結果總是相同的（如：任何數不管乘零多少次結果總是零），除非底層資源發生變化。
3 以一個Web地圖服務為例
這是《RESTful Web Services》書中一個最簡單的例子，因為Web地圖是只讀的服務。我只是簡單總結，以便大家對REST風格的架構有一個直觀的認識。
設計步驟如下：
l 分析數據集
l 將數據集劃分為資源
對每一個資源
l 用URI給資源定名
l 選擇統一介面方法
l 設計客戶端→伺服器的表述
l 設計伺服器→客戶端的表述
l 用超媒體鏈接或表單將資源掛接到現有資源鏈中
l 正面設想一下該發生什麼
l 反面設想一下什麼可能發生

（1） 分析數據集
本數據集為各大星球二維平面圖，可以通過地理坐標及地名在地圖上定位，並展示以點為中心的平面圖。
（2） 將數據集劃分為資源
資源大體分三類：
l 預定義的一次性資源，如同一個web主頁，充當其它資源的頂級入口。你能GET它，但不能DELETE或PUT它。
l 每個對象的資源，每個對象有自己的資源集合，你可以GET、DELETE或PUT對象的資源。
l 經數據處理後獲取的資源，例如根據查詢條件返回的結果。

2、REST和SOAP Web Service的區別比較

restful是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動。

SOAP：簡單對象訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞消息（Http,SMTP等）。

客戶端和伺服器端的通訊方式 

REST 與代理伺服器 (Proxy Servers)  

一般代理伺服器的實現根據 (URI, HTTP Method) 兩元組來決定 HTTP 請求的安全合法性。

當發現類似於（http://localhost:8182/v1/users/{username}，DELETE）這樣的請求時，予以拒絕。

對於 SOAP，如果我們想藉助於既有的代理伺服器進行安全控制.

REST 與緩存伺服器 (Cache Server)  

使用 HTTP 協議的 SOAP，由於其設計原則上並不像 REST 那樣強調與 Web 的工作方式相一致，所以，基於 SOAP 應用很難充分發揮 HTTP 本身的緩存能力,圖 7. SOAP 與緩存伺服器 (Cache Server)

總結：

REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。成熟度SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發布和調用，以及廠商的支持都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來交互的web service都能夠較好的互通。

3、怎樣用通俗的語言解釋什麼叫 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 樣式的架構中

4、REST真的完全適合微服務架構嗎

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 服務本質上是互為補充的。

5、怎樣保證到伺服器的 REST 請求是由自己的 APP 發起的

簡單而直接的答案是：不可能杜絕，盡量減小影響。
Report: Bot traffic is up to 61.5% of all website traffic
2014 Bot Traffic Report: Just the Droids You were Looking for
根據這兩篇報道，2013年全球Web流量61.5%是機器人，2014年是56%。

這是一個很有普遍意義的反機器人設計，雖然結果令人失望，但是我們可以從技術角度做一些事情：
0 反作弊策略
最最最重要的！要有反作弊策略，不能只依靠技術手段。這是一個與人斗的過程。
至少你要定義出什麼樣的行為是機器人，比如每秒30個請求顯然不是個真實用戶。
1 SSL
先從最簡單的入手。用SSL可以杜絕最簡單的抓包探測。
2 雙向加密
題目中的非對稱加密方法。當然別人可以反編譯你的客戶端，但是要學會反編譯，戰勝那些混淆代碼的工具，需要比較高的專業技能。
3 第三方認證
目前手機是沒有，但是XBOX和PS都有。只要這些第三方平台沒有被破解，你就可以通過伺服器間通訊獲得可靠的用戶信息。
其實蘋果的DeviceToken就是這個東西，但是它沒有提供介面讓你驗證合法性，就等於沒有了。

除了技術手段以外，更重要的是運營策略：
1 利益是源頭
別人調你的API一定是有用，如果是游戲一般都是刷金幣對吧。你控制不要刷出來，自然就沒有人刷了。
2 關閉交易通道
攻擊你的人一定要有經濟利益才會持續的投入，否則就是玩玩。不要讓他們賺到錢，就像魔獸世界一樣把刷金幣和買金幣的賬號都封掉。這是從制度上消滅它的利益。
3 提高成本
再嚴密都會有疏漏，比如你的反作弊策略只能覆蓋70％的BOT，另外30%的收益依然可能大於成本。這時候可以提高創建新用戶的成本，比如第三方硬體平台其實就是一種，你也可以對每個新建的賬號收費，收到超過它的平衡點就自然會退出了。

6、在rest介面規范中，post成功創建一個新的資源後，伺服器應該返回狀態碼是多少

2xx
200 OK
所有人都知道 200 OK 是什麼。這估計是最經常被濫用的狀態碼。很多人在應該使用其它 2xx 狀態碼時都選用了 200 OK 來表示。
201 Created
如果你在設計一個 REST API，或者一個 CRUD API，當你使用 POST（或者 PUT）成功創建一個新的資源後，伺服器應該返回 201 Created 同時在 header 的 Location 欄位給出剛剛創建好的這個資源的 URI。
例如說，如果你使用 POST 請求通過 \comments URI 創建了一個新的評論，那麼伺服器應該返回 201 Created，同時帶上形如Location: \comments\1234 的欄位表明新創建的評論的 URI。
202 Accepted
如果伺服器在接受請求後，需要進行一個非同步處理才能有結果，並且覺得不需要讓 TCP 連接保持到結果出來再返回，它可以返回 202 Accepted，意思是請求已接受，但沒有立即可返回的結果。
204 No Content
在一個 REST API 或者 CRUD API 裡面，當你使用 PUT 成功更新一個資源後，如果伺服器完整接受了客戶端的更新，沒有拒絕也沒有額外更新，那實際上是不需要返回任何東西的，因為現在客戶端和伺服器端已經擁有完全一致的狀態。在這種情況下，伺服器可以返回 204 No Content，同時 body 為空，客戶端就知道它的狀態已經跟伺服器端同步了。
206 Partial Content
斷點續傳和多線程下載都是通過 206 Partial Content 實現的。
請求的 header 必須包含一個 Range 欄位，表明自己請求第幾個位元組到第幾個位元組的內容。如果伺服器支持的話，就返回 206 Partial Content，然後使用 header 的 Content-Range 指明範圍，並在 body 內提供這個范圍內的數據。
3xx
301 Moved Permanently
永久性重定向。目標由 header 的 Location 欄位給出，同時 body 中也應該有指向目標的鏈接。新請求使用的方法應該和原請求的一致。如果用戶使用 HEAD 和 GET 以外的方式發起原請求，客戶端在遇到 301 Moved Permanently 後應當詢問用戶是否對新的 URI 發起新請求。
302 Found
臨時性重定向。
這應該是瀏覽器實現最不符合標準的一個狀態碼了。理論上，除了臨時性這一點，302 Found 跟 301 Moved Permanently 應該是完全一樣的。然而實質上，很多瀏覽器在遇到 302 Found 後就會使用 GET 去請求新的 URI，而無論原請求使用的是何種方法。由於這種現象的普遍存在，使得這成為了一個與書面標准相違背的事實標准，新的客戶端在實現時很難選擇應該遵守哪一個標准，所以 RFC 2616 專門新增了 303 See Other 和 307 Temporary Redirect 兩個狀態碼來消除二義性。
303 See Other
臨時性重定向，且總是使用 GET 請求新的 URI。
304 Not Modified
如果客戶端發起了一個「條件 GET」，同時資源確實沒被修改過，那麼伺服器端就應該返回 304 Not Modified，同時 body 不包含任何內容。
所謂的「條件 GET」，是指 GET 的 header 帶上了 If-Modified-Since 或 If-None-Match 欄位。這兩個 header 就是「條件」，如果條件符合了 GET 就應該正常執行，否則就應該返回 304 Not Modified，以便告訴客戶端它想要請求的資源在上一次請求之後沒有被更新過，客戶端可以繼續使用之前的版本。
307 Temporary Redirect
臨時性重定向，且總是使用原請求的方法來進行新請求。
4xx
400 Bad Request
伺服器無法理解請求的格式，客戶端不應當嘗試再次使用相同的內容發起請求。
401 Unauthorized
請求未授權。如果請求 header 沒有 Authorization 欄位，伺服器端應該在返回 401 Unauthorized 的同時在 header 中用 WWW-Authorization 欄位指出授權方式，以便客戶端帶上登錄信息重新發起請求。如果 Authorization 欄位已經存在，則表明登錄信息不正確。
402 Payment Required
需要支付。這是一個在任何瀏覽器中都沒有被實現的狀態碼，僅預留將來使用。
百度曾經有一個部門印過一批背上寫著 402 Payment Require 的衣服，並且開玩笑說這批衣服最適合在互聯網企業員工討薪時穿。
403 Forbidden
禁止訪問。即使使用 Authorization 欄位提供登錄信息也會得到相同的結果。
如果客戶端使用 HEAD 以外的方法請求，403 Forbidden 必須同時在 body 中返回禁止訪問的原因。如果原因不能夠公開，則應該使用404 Not Found。
404 Not Found
找不到如何與 URI 相匹配的資源。伺服器無需指出資源是臨時性不存在還是永久性不存在，但如果伺服器端知道該資源已經被永久性刪除則應該返回 410 Gone。
404 Not Found 是伺服器端在不願意提供理由的情況下拒絕提供資源的最佳借口。
405 Method Not Allowed
請求的方法被拒絕。
如果你有一個 REST API 或 CRUD API 被設計為只讀，那麼在遇到 PUT、POST 或者 DELETE 方法時伺服器端都應該返回 405 Method Not Allowed，同時在 header 的 Allow 欄位說明允許的方法（如 GET 和 HEAD）。
409 Conflict
沖突，且需要用戶手工解決。
如果你使用 git（或者其他源代碼管理軟體），你已經知道「沖突」是什麼了。409 Conflict 通常發生在 PUT 請求時，如果要更新的資源已經被其他人更新過了，你再更新就可能產生沖突。
410 Gone
如果伺服器端將此資源標記為已被永久性刪除，則應該使用 410 Gone 而非 404 Not Found，其用意在於告訴客戶端資源是被有意刪除的，而且刪除是永久性的，客戶端不應該再保留這個 URI 的鏈接。
舉例來說，你有一個 REST API 或 CRUD API 用於向用戶提供優惠信息。有一則優惠的 URI 是 /promotions/1234，但由於優惠活動已經結束了，所以這一則優惠信息不再有效且應當被永久性刪除，那麼這時候伺服器端就應該讓該 URI 永遠返回 410 Gone 了。
412 Precondition Failed
條件判斷失敗，操作不會被執行。
在解釋 304 Not Modified 時提到了「條件 GET」的概念，但「條件」本身也可以應用於非 GET 請求，這時候如果條件判斷失敗伺服器端就應該返回 412 Precondition Failed，同時拒絕執行客戶端請求的方法。
條件請求可以被看作是一種樂觀鎖。它不需要伺服器端有任何邏輯判斷操作是否存在沖突，伺服器端只要記錄資源的時間戳（或其它版本信息）即可。
5xx
500 Internal Server Error
最常見的伺服器端錯誤。
503 Service Unavailable
伺服器端暫時無法處理請求（可能是過載或維護）。
返回 503 Service Unavailable 的意思是當前的狀況是臨時性的，客戶端可以稍後重試。伺服器端可以在返回時通過 header 的Retry-After 欄位告訴客戶端多久後可以重試。如果不提供這個欄位的話，客戶端應當把 503 Service Unavailable 等同於 500 Internal Server Error 處理。

7、如何使用JFINAL搭建REST介面伺服器

2.7 configHandler(..)
此方法用來配置JFinal的Handler，如下代碼配置了名為ResourceHandler的處理器，Handler可以接管所有web請求，並對應用擁版有完全的控制權，可權以很方便地實現更高層的功能性擴展。
public void configHandler(Handlers me) { me.add(new ResourceHandler());}

8、什麼是REST-ful，以及REST-ful的實現

REST 指的是一組架構約束條件和原則
Web 應用程序最重要的 REST 原則是：客戶端和伺服器之間的交互，在請求之間是無狀態的；客戶端的每個請求都必須包含理解請求所必需的信息；伺服器在請求之間的任何時間點重啟，客戶端 不會得到通知；無狀態請求可以由任何可用伺服器回答，十分適合雲計算之類的環境；客戶端可以緩存數據以改進性能。
在伺服器端，應用程序狀態和功能可以分為各種資源：每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的界面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。
另一個重要的 REST 原則是分層系統：這表示組件無法了解它與之交互的中間層以外的組件。通過將系統知識限制在單個層，可以限制整個系統的復雜性，促進了底層的獨立性。
當 REST 架構的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和伺服器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和伺服器的實現。
REST-ful的實現：構建 RESTful Web 服務的多層架構
RESTful Web 服務和動態 Web 應用程序在許多方面都是類似的。有時它們提供相同或非常類似的數據和函數，盡管客戶端的種類不同。例如，在線電子商務分類網站為用戶提供一個瀏覽器界面， 用於搜索、查看和訂購產品。如果還提供 Web 服務供公司、零售商甚至個人能夠自動訂購產品，它將非常有用。與大部分動態 Web 應用程序一樣，Web 服務可以從多層架構的關注點分離中受益。業務邏輯和數據可以由自動客戶端和 GUI 客戶端共享。惟一的不同點在於客戶端的本質和中間層的表示層。此外，從數據訪問中分離業務邏輯可實現資料庫獨立性，並為各種類型的數據存儲提供插件能力。

9、移動App開發的後台REST伺服器有哪些

如果你喜歡自己搭建而且是iOS

如果你在國內AVOS, 國外Parse

也有一些其他選擇

10、什麼是REST?

它首次出現在 2000 年 Roy Fielding 的博士論文中，他是 HTTP 規范的主要編寫者之一。
REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。
Web 應用程序最重要的 REST 原則是，客戶端和伺服器之間的交互在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的信息。如果伺服器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用伺服器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。
在伺服器端，應用程序狀態和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程序對象、資料庫記錄、演算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的界面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態的引擎，資源表示通過超鏈接互聯。
另一個重要的 REST 原則是分層系統，這表示組件無法了解它與之交互的中間層以外的組件。通過將系統知識限制在單個層，可以限制整個系統的復雜性，促進了底層的獨立性。
當 REST 架構的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和伺服器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。