RESTful Web APIs中文版 下載 mobi epub pdf 電子書 2024

編輯推薦

　　近年來，REST的流行導緻瞭各種“RESTful”API的巨大增長，但是這些API卻錯失瞭很多架構的好處。通過這本實用指南，你將可以學習到如何設計可用的，並能隨著時間不斷進化的REST API。通過專注於跨多種領域的解決方案，本書嚮你展示瞭該如何使用那些為世界上成功的分布式計算係統——萬維網而設計的工具，從而來 創建強大且安全的應用。你將探索REST背後的概念，學習多種可用於創建基於超媒體API的策略，並在本書一步步的指導下整閤你所學到的所有內容，從而去設計RESTful的web API。

　　√ 審查瞭包括集閤模式和純超媒體在內的API設計策略。

　　√ 理解如何將超媒體與錶述整閤進一個一緻的API。

　　√ 探索XMDP和ALPS profile格式是如何幫助你應對web API的“語義挑戰”的。

　　√ 學習近二十多種標準化的超媒體數據格式。

　　√ 應用在API實現中使用HTTP的實踐。

　　√ 使用JSON-LD標準及其他Linked Data方法來創建web API。

　　√ 理解在嵌入式係統使用REST的CoAP協議。

內容簡介

　　《RESTful Web APIs中文版》是針對RESTful API的實用指南，通過展示各種用來創建高可用應用的強大工具，講解REST的深層原理，以及介紹基於超媒體API的策略，使讀者得以在將上述內容融會貫通後，設計齣讓客戶高度滿意的RESTful的web API。本書極具專業性與前瞻性，既代錶瞭API領域的前沿趨勢，也覆蓋瞭API領域的重要實踐。

作者簡介

　　Leonard Richardson， 《Ruby Cookbook》 （O’Reilly）一書的作者，曾 創建瞭包括Beautiful Soup在內 的多個開源代碼庫。Mike Amundsen 是包括《Building Hypermedia APIs with HTML5 and Node》（O’Reilly） 在內的十幾本為人所稱道的技術圖書的作者。

目錄

序
前言
第1章 網上衝浪
場景1：廣告牌
資源和錶述
可尋址性
場景2：主頁
短會話（Short Session）
自描述消息（self-descriptive message）
場景3：鏈接
標準方法
場景4：錶單和重定嚮
應用狀態（Application State）
資源狀態（resource state）
連通性（connectedness）
與眾不同的Web
Web API落後於Web
語義挑戰
第2章 一個簡單的API
第3章 資源和錶述
第4章 超媒體
第5章 領域特定設計
第6章 集閤模式（Collection Pattern）
第7章 純-超媒體設計
第8章 Profile
第9章 API設計流程
第10章 超媒體動物園
第11章 API中的HTTP
第12章 資源描述和Linked Data
第13章 CoAP：嵌入式係統的REST
附錄
詞匯錶

精彩書摘

　　“大多數軟件係統在創建時都有一個隱含的假設：整個係統處在一個實體的控製之下；或者至少參與到係統中的所有實體都嚮著一個共同目標行動，而不是有著各自不同的目標。當係統在互聯網上開放地運行時，無法安全地滿足這樣的假設。”
　　——RoyFielding
　　ArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures“Discordia信徒應該一直使用官方的Discordian文檔編號係統。”
　　——MalaclypsetheYounger和LordOmarKhayyamRavenhurst
　　我要嚮你展示一種可以更好地進行分布式計算的方式，它使用瞭有史以來最成功的分布式係統，即萬維網的根本思想。如果你已經決定（或者你的經理已經決定）需要為你的公司發布一個webAPI的話，我希望你能夠讀一下這本書。不管在你計劃中的是一個公共的API，還是一個純粹的內部API，抑或是一個隻有受信夥伴可以訪問的API——它們都可以從REST的哲學中受益。
　　如果你想學習如何編寫API客戶端的話，那麼這本書對你來說並不是必要的。這是因為大多數現有的API設計都基於一些有著數年之久的假設，而這些假設正是我想要摧毀的。
　　大部分今天的API都有著一個很大的問題：一旦部署，它們將無法改變。有一些大名鼎鼎的API會在一次部署後多年保持靜態不變，即使圍繞它們的行業發生著改變，這是因為要改變它們非常睏難。
　　但是RESTful架構是為掌控變化而設計的。萬維網由數百萬的網站組成，運行在數韆種不同的服務器實現之上，並且經曆著周期性的重新設計。這些網站被數十億的用戶訪問著，而這些用戶使用著幾十種硬件平颱之上的數百種不同的客戶端實現。你的部署在一開始可能看上去不會如此混亂，但是當你的應用越發接近web的規模時，你將會看到越發相似的混亂景象。
　　要改變一個非常簡單的係統通常都是很容易的。在規模很小時，一個RESTful係統比一個一鍵式的解決方案（push-buttonsolution）需要花費更多預支的設計成本。但是當你的API逐漸成熟並開始發生變化時，你將會真正需要一些像REST這樣的方式來應對變化。
　　y一個商業上成功的API將保持連續多年的可用。一些API擁有數百甚至是數以韆計的用戶。就算問題域隻是偶然地發生變化，對客戶端帶來的纍積效應將是非常大的。
　　y有一些API一直都在發生變化，新的數據元素和業務規則不斷地被添加進來。
　　y在某些API中，每個客戶端都可以通過改變工作流來使其適閤自己的需求。即使API自身從不變化，每個客戶端對API的經曆（鑒於經曆不同的工作流）將會不同。
　　y編寫API客戶端的人通常不會和編寫服務器的人隸屬於同一個團隊。所有嚮公共開放的API都屬於這一類。
　　如果你不知道外部的客戶端是哪種類型的話，你需要在做齣變化時格外小心——否則你就需要一個能夠在發生變化時保證不會破壞所有客戶端的設計。如果你為你的API復製瞭現有的設計，你將很可能隻是在重復以往犯過的錯誤。不幸的是，大部分的改進發生在幕後，它們大都還處於實驗階段並需要經過漫長的標準流程。我將會在本書中討論到數十種特定的技術，包括很多還仍然處於開發之中。但是我的主要目標是要教會你REST的基本原則。通過對這些內容的學習，你將可以對任何實驗成果以及那些通過流程審核的標準善加利用。
　　這裏有兩個我想在本書中嘗試解決的具體問題：重復的工作以及對超媒體的逃避。讓我們來看看它們。
　　重復的工作
　　現今已發布的API都是根據托管它們的公司的名字進行命名的。我們談論著“TwitterAPI”、“FacebookAPI”和“Google+API”。這三套API做著相似的事情。它們都擁一些用戶賬戶的概念，（在其他方麵）它們都允許用戶嚮自己的賬戶發布文本信息。但是每個API都具有完全不同的設計，學習一個API並不能幫助你學習下一個。當然，Twitter、Facebook和Google都是互相競爭的大型公司，它們並不想讓你很容易地就學會它們競爭對手的API。但是小公司和非營利性組織也在做著相同的事。它們重新設計著自己的API，就好比從來沒有人在這方麵有過相似的想法一樣，但是這乾擾瞭它們想讓人們實際使用它們的API的目標。
　　讓我來嚮你展示一個例子吧。網站ProgrammableWeb（http：//www。programmableweb。com/）擁有著一個超過8000個API的目錄。當我正在編寫此書之時，它已經收錄瞭57種微博API——這些API的主要用途是嚮用戶的賬戶發布文本信息注2。很不錯，有57傢公司在這個領域發布瞭API，但是我們真的需要57種不同的設計嗎？我們在這裏討論並不是那些復雜難懂的業務，例如保險政策或法規守則，我們討論的隻是嚮用戶賬號發布少量的文本信息。你想成為那個設計第58種微博API的人嗎？
　　最顯而易見的解決方案便是創建一個微博API的標準。但是我們已經有瞭一個可以很好工作的標準：Atom發布協議（AtomPublishingProtocol）。它發布於2005年，然而幾乎沒有人使用它。有一些關於API的原因，使得每個人都想從頭開始設計他們自己的API，即使從業務的角度來看這並沒有什麼意義。
　　我不認為憑我一個人的力量就能結束這種無用功，但是我確實認為可以將問題分解成若乾有意義的小塊，然後提供一些方式來讓新的API可以復用已經完成的這些工作。
　　超媒體很難
　　早在2007年，LeonardRichardson和SamRuby編寫瞭本書的前身，RESTfulWebServices(O‘Reilly)。那本書同樣也嘗試於解決兩個大的問題。其中一個問題已經被解決，而另一個卻沒有任何進展。
　　第一個問題是：在2007年，在API設計的多個陣營中，REST學派正在與使用基於SOAP等重量級技術的對手學派進行對峙，他們忙於應對來自對方的對REST學派閤理性的質疑。RESTfulWebServices一書的齣現打破瞭這種對峙的僵局，有效地為RESTful設計原則防禦瞭來自SOAP學派的進攻。
　　很好，這場對峙已經結束，而REST贏得瞭勝利。SOAPAPI仍在被使用著，不過僅限於那些起初支持SOAP學派的大公司。幾乎所有麵嚮公眾的API口頭上都說自己遵守瞭RESTful原則。
　　這又將我們帶到瞭第二個問題：REST並不隻是一個技術詞匯——它同樣還是一個營銷術語。在很長一段時間裏，REST成瞭一個口號，它象徵著任何站在SOAP學派對立麵的勢力。任何沒有使用SOAP的API都將自己標榜為REST，即使它的設計與REST毫無關係甚至是違背瞭REST的基本原則。這樣做是錯誤的，是令人睏惑的，它給REST這個技術詞匯帶來瞭一個壞名聲。
　　這種情況自2007年便有瞭較大的改善。每當我審視那些新的API，我看到瞭開發者們的工作，可以看得齣，這些開發人員是理解那些我將在本書前幾章中解釋的概念的。今天大部分舉著REST大旗的開發者都理解資源和錶述，理解如何使用URL來為資源命名，以及如何正確地使用HTTP方法。因此本書的前三章將不需要做過多的事情，隻需讓新的開發者加速趕上我們即可。
　　但是在REST中，還有一個方麵令大部分的開發人員仍然無法理解，即：超媒體。我們都理解Web環境中的超媒體。它隻是作為代錶鏈接的一個華麗的詞匯。網頁經過互相的鏈接，隨即産生瞭萬維網，萬維網便是由超媒體驅動的。但是，貌似隻要在webAPI中涉及到超媒體，我們便有瞭心理障礙。這是一個大問題，因為超媒體是一項能讓webAPI優雅處理變化的特性。
　　從RESTfulWebAPIs一書的第４章開始，我的首要目標便是教會你超媒體的工作原理。如果你從未聽到過這個詞，我將會結閤其他重要的REST概念嚮你講授該詞。如果你聽到過超媒體，但是這個概念嚇到瞭你，我將會盡我所能來為你建立勇氣。如果你無法將超媒體裝進你的大腦，我將會以各種我所能想到的方式來嚮你展示超媒體，直到你記住並理解它。
　　RESTfulWebServices一書也涉及到瞭超媒體，但是這並不是該書的重心所在。就算跳過該書的超媒體部分也可以照樣設計齣一個功能性的API。相比之下，RESTfulWebAPIs則是一本真正有關超媒體的書。
　　我之所以這樣做是因為超媒體是REST最重要的一個方麵，也是最不被理解的一個方麵。在我們完全理解超媒體之前，REST將會被繼續視為一個營銷術語，而不是對處理分布式計算復雜性的一次認真的嘗試。
　　……

前言/序言

沒看完，好像沒那麼好

內容缺乏實戰，一般般吧

非常好呀，非常好，非常好11111111

很不錯的東西，快遞速度也很快，超級棒?

不錯 特彆是api那章

理解restful，做移動app

質量不錯，和圖片一樣。專業必備，性價比高~~~

此用戶未及時評價，係統默認好評。

我們這裏的京東配送員特彆好，每次都提前告知，態度很好而且送達率超高！有時候特殊情況不在傢特地再跑一次。給京東配送員點贊，希望京東一直能保持好品質。