❶ RESTful WebService和web service的區別
restful是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動。
SOAP：簡單對象訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞消息（Http,SMTP等）。
客戶端和伺服器端的通訊方式
總結：
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。成熟度SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發布和調用，以及廠商的支持都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來交互的web service都能夠較好的互通。
❷ 什麼是RESTful Web Service
其實早在web service概念產生前就有了restful的概念，或者說restful是和Http一起誕生的。
可以參閱 Roy Fielding 的論文「Architectural Styles and the Design of Network-based Software Architectures」， 我本身並沒有讀過。
Restful的意思是『寧靜的』，你可以理解為『簡約而不簡單』，或者『和諧的』。一個協議只有足夠的簡約才有擴展性和生命力，復雜的東西往往伴隨的是大量bug和規模膨脹後的不可控。
Restful就是Http的本質，僅僅是一個資源URI，和Get，Post，Put，Delete四種操作。一切Web的行為皆源於此。
所以早期的網站，或者說是靜態的網站的都是Restful的，如果廣義的把瀏覽器獲取web page當做一種web service的話，那麼他們都提供了Restful Web Service。
所以Restful並不是個陌生的概念，更不是個新的概念，只不過是一直被忽略了。
一樣東西之所以被忽略，因為沒有對立面， 或者說沒有可比較的東西。世界上的概念都是相對的，有了丑才有美，有了胖才有瘦。
同樣當僅僅只有restful的時候，便很少有人真正了解restful的意思。
直到有一天，restful的原則被打破，世界上出現了非restful的web行為，我們可以把它稱做『RPC-style』的web service。
❸ 我怎樣寫，它接受一個二進制文件RESTful Web服務
fopen(filename,"w+b")例如FILE*fp=fopen("test.dat","wb+")；--詳細說明fopen()函數的用法fopen函數用於打開文件,其調用格式為:FILE*fopen(char*filename,*type);fopen()函數中第一個形式參數表示文件名,可以包含路徑和文件名兩部分。如:"B:TEST.DAT""C:\\TC\\TEST.DAT"注意：如果將路徑寫成"C:\TC\TEST.DAT"是不正確的,這一點要特別注意。fopen函數用來打開一個文件，其調用的一般形式為：文件指針名=fopen(文件名，使用文件方式)其中，「文件指針名」必須是被說明為FILE類型的指針變數，「文件名」是被打開文件的文件名。「使用文件方式」是指文件的類型和操作要求。「文件名」是字元串常量或字元串數組。例如：FILE*fp；fp=("filea","r");其意義是在當前目錄下打開文件filea，只允許進行「讀」操作，並使fp指向該文件。又如：FILE*fphzkfphzk=("c:\\hzk16',"rb")其意義是打開C驅動器磁碟的根目錄下的文件hzk16，這是一個二進制文件，只允許按二進制方式進行讀操作。兩個反斜線「\\」中的第一個表示轉義字元，第二個表示根目錄。使用文件的方式共有12種，下面給出了它們的符號和意義。第二個形式參數表示打開文件的類型。關於文件類型的規定參見下表。表文件操作類型━━━━━━━━━━━━━━━━━━━━━━━━━━━━字元含義————————————————————————————"r"打開文字文件只讀"w"創建文字文件只寫"a"增補,如果文件不存在則創建一個"r+"打開一個文字文件讀/寫"w+"創建一個文字文件讀/寫"a+"打開或創建一個文件增補"b"二進制文件(可以和上面每一項合用)"t"文本文件(默認項)
❹ restful和webservice的怎麼選
您好！一下為個人看法，希望能對您有幫助，滿意的麻煩給個採納，謝謝了！
從基本原理層次上說，REST 樣式和 SOAP 樣式 Web Service的區別取決於應用程序是面向資源的還是面向活動的。例如，在傳統的WebService中，一個獲得天氣預報的webservice會暴露一個WebMethod：string GetCityWether（string city）。而RESTful WebService暴露的不是方法，而是對象（資源），通過Http GET, PUT, POST 或者 DELETE來對請求的資源進行操作。在 REST 的定義中，一個 Web Service總是使用固定的 URI 向外部世界呈現（或者說暴露）一個資源。可以說這是一種全新的思維模式：使用唯一資源定位地址 URI，加上 HTTP 請求方法從而達到對一個發布於互聯網資源的唯一描述和操作。
所以我理解為rest架構定義的webservice實際上定義了一個借口的規范。
REST其實並不是什麼協議也不是什麼標准，而是將Http協議的設計初衷作了詮釋，在Http協議被廣泛利用的今天，越來越多的是將其作為傳輸協議，而非原先設計者所考慮的應用協議。
REST的思想歸結以下有如下幾個關鍵點：
1．面向資源的介面設計
所有的介面設計都是針對資源來設計的，也就很類似於我們的面向對象和面向過程的設計區別，只不過現在將網路上的操作實體都作為資源來看待，同時URI的設計也是體現了對於資源的定位設計。後面會提到有一些網站的API設計說是REST設計，其實是RPC-REST的混合體，並非是REST的思想。
2．抽象操作為基礎的CRUD
這點很簡單，Http中的get,put,www.hbbz08.com post,delete分別對應了read,update,create,delete四種操作，如果僅僅是作為對於資源的操作，抽象成為這四種已經足夠了，但是對於現在的一些復雜的業務服務介面設計，可能這樣的抽象未必能夠滿足。其實這也在後面的幾個網站的API設計中暴露了這樣的問題，如果要完全按照REST的思想來設計，那麼適用的環境將會有限制，而非放之四海皆準的。
3．Http是應用協議而非傳輸協議
這點在後面各大網站的API分析中有很明顯的體現，其實有些網站已經走到了SOAP的老路上，說是REST的理念設計，其實是作了一套私有的SOAP協議，因此稱之為REST風格的自定義SOAP協議。
4．無狀態，自包含
這點其實不僅僅是對於REST來說的，作為介面設計都需要能夠做到這點，也是作為可擴展和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。
❺ webservice和restful的區別
restful是一種架構風格，其核心是面向資源；而webService底層SOAP協議，主要核心是面向活動。
SOAP：簡單對象訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞消息（Http,SMTP等）。
客戶端和伺服器端的通訊方式
總結：
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。
成熟度
SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務發布和調用，以及廠商的支持都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來交互的web service都能夠較好的互通。
❻ RESTful Web API 具有怎樣的特徵
Yii框架 Yii是一個基於組件、用於開發大型 Web 應用的 高性能 PHP 框架。Yii 幾乎擁有了 所有的特性 ，包括 MVC、DAO/ActiveRecord、I18N/L10N、caching、基於 JQuery 的 AJAX 支持、用戶認證和基於角色的訪問控制、腳手架、輸入驗證、部件
❼ 如何實現RESTful Web API的身份驗證
最近想拿一個小項目來試水RESTful Web
API，項目只有幾個調用，比較簡單，但同樣需要身份驗證，如果是傳統的網站的話，那不用說，肯定是用戶名+密碼在登錄頁獲得登錄Token，並把登錄
Token記在Cookie和Session中作為身份標識的這種方式，但現在不同了，關鍵是RESTful，這意味著我們設計出來的這些API是無狀態
的（Stateless），下一次的調用請求和這一次的調用請求應該是完全無關的，也就是說，正宗的RESTful Web
API應該是每次調用都應該包含了完整的信息，沒錯，包括身份信息！
那如何確保安全？傳輸時給密碼做MD5加密？得了吧！這樣做只能讓你自己感覺「安全」點，其實沒什麼任何用處，利用現在的技術（有種叫什麼Rainbow Table啥的來著？本人外行，不是很懂）很快就能算出明文密碼了，而且如何防止挾持和重發攻擊？
也許你想到了，SSL，如果你打算採用SSL，請忘記一切自行設計的加密方案，因為SSL已經幫你做好了一切，包括防止監聽，防止挾持，防止重發……一切都幫你考慮好了，你大膽地把明文密碼寫在你的包中就OK了，我向你保證沒問題。
但SSL的缺點是伺服器端配置相對有點復雜，更關鍵的就是客戶端對此支持可能不好，那你考慮一種自己的加密方法，有木有？我這里提供一種方法，思路來自
於：http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-
authentication/，我只是把上面的內容中整理了一下變成了我的方法。（傳說中的剽竊？呵呵）方法描述如下：
假設有一個用戶，用戶名是guogangj，密碼是123456（呃……這也能叫密碼？）
他要GET http://test.com/api/orders/
於是把 http://test.com/api/orders/這個URL和一個新生成的GUID拼在一起，再用123456這個密碼執行對稱加密，生成的密文為XXXXOOOOXXXXOOOO（假設而已）
數據包中帶上用戶名guogangj和XXXXOOOOXXXXOOOO這個密文，發送給伺服器
伺服器收到包後，根據guogangj這個用戶名到資料庫中查找到123456這個密碼
伺服器使用123456這個密碼來解密XXXXOOOOXXXXOOOO這個密文，得到了明文，即http://test.com/api/orders/這個URL和前面由客戶端生成的那個GUID
伺服器到一個全局的集合中查找這個GUID，看看是否已經存在，如果存在，則驗證不通過，如果不存在，就將其放入這個集合中。這是為了避免重發攻擊。這個全局的集合會越來越大，所以還要定期清理。
伺服器再比對解密出來的URL和用戶真實請求的URL是否一致，如果一致，那麼認為這是合法用戶，驗證通過！
這是大致過程，如果資料庫里找不到該用戶，或者解密錯誤，都被認為驗證不通過。以下是一些改進：
資料庫中的密碼最好做一下摘要（MD5之類的），客戶端對應地也要做一下。
在生成密文的時候可以考慮加入另外一些不希望被明文傳輸的敏感內容，甚至可以加入IP地址，並在伺服器端驗證。
並
非每次都要真正去資料庫里拿一次用戶信息，也許你有更好的辦法，比如一個簡單的緩存（不過需要處理緩存更新的問題），或者當你的系統大到一定程度的時候，
你考慮使用統一的服務來獲取用戶信息，這就不是緩存那麼簡單了，裡面的文章很多，我相信現在大規模的門戶網站都有自己的一套復雜的機制，所以表明上看
RESTful Web API很「低效」，但這種RESTFul的思路和模式卻在實際中有很大的可塑性和威力。
這種方法應該足夠安全了！
密碼根本沒有在網路上傳輸，密文採用的是非驗證的對稱加密，沒有密鑰就無法逆轉，URL驗證避免了傳統的身份挾持攻擊（即攔截一個用戶的包並冒充此用戶來訪問其它的資源，即便無法破解用戶密碼）， 再用GUID來避免了重發攻擊，唯一需要擔心的是用戶泄露了自己的密碼。
❽ "SOAP WebService " 和 "RESTful WebService" 的區別和聯系
SOAP(Simple Object Access Protocol)簡單對象訪問協議，是基於HTTP的一種異構系統通信的協議，說白了就是xml文檔傳輸，之所以會有它，就是在於不同語言C,C++,JAVA等語言開發的系統進行通信，是WebService就是基於SOAP協議的，確實是一種比較傳統的SOA解決方案。
REST(Rerepresentational State Transfer)是外國一位博士提出的一種架構風格，從資源狀態轉換角度看待資源，但也是基於SOAP協議進行通信。
rest 是一種風格 restful Webservice 和 soap的區別在於表現形式不一樣，如果想深入了解 可以去開開 深入理解Webservice 這本書，restful Webservice 不只是可以用json 也可以用xml 更可以用html做消息返回， rest 風格的Webservice 和傳統的soap 主要的表現在於 rest是將資源暴露 soap是暴露操作 。具體的流程其實和soap是一樣的，但是rest更方便，更輕。