Muutke küpsiste eelistusi

RESTful Web APIs [Pehme köide]

3.71/5 (526 hinnangut Goodreads-ist)
  • Formaat: Paperback / softback, 379 pages
  • Ilmumisaeg: 29-Oct-2013
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1449358063
  • ISBN-13: 9781449358068
Teised raamatud teemal:
  • Pehme köide
  • Hind: 43,68 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Tavahind: 51,39 €
  • Säästad 15%
  • Raamatu kohalejõudmiseks kirjastusest kulub orienteeruvalt 2-4 nädalat
  • Kogus:
  • Lisa ostukorvi
  • Tasuta tarne
  • Tellimisaeg 2-4 nädalat
  • Lisa soovinimekirja
RESTful Web APIsSuurem pilt
  • Formaat: Paperback / softback, 379 pages
  • Ilmumisaeg: 29-Oct-2013
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1449358063
  • ISBN-13: 9781449358068
Teised raamatud teemal:
Püsilink: https://www.kriso.ee/db/9781449358068.html
Märksõnad:

The popularity of REST in recent years has led to tremendous growth in almost-RESTful APIs that don’t include many of the architecture’s benefits. With this practical guide, you’ll learn what it takes to design usable REST APIs that evolve over time. By focusing on solutions that cross a variety of domains, this book shows you how to create powerful and secure applications, using the tools designed for the world’s most successful distributed computing system: the World Wide Web.

You’ll explore the concepts behind REST, learn different strategies for creating hypermedia-based APIs, and then put everything together with a step-by-step guide to designing a RESTful Web API.

  • Examine API design strategies, including the collection pattern and pure hypermedia
  • Understand how hypermedia ties representations together into a coherent API
  • Discover how XMDP and ALPS profile formats can help you meet the Web API "semantic challenge"
  • Learn close to two-dozen standardized hypermedia data formats
  • Apply best practices for using HTTP in API implementations
  • Create Web APIs with the JSON-LD standard and other the Linked Data approaches
  • Understand the CoAP protocol for using REST in embedded systems
Foreword xiii
Introduction xv
1 Surfing the Web 1(16)
Episode 1: The Billboard
2(1)
Resources and Representations
2(1)
Addressability
3(1)
Episode 2: The Home Page
3(3)
Short Sessions
4(1)
Self-Descriptive Messages
5(1)
Episode 3: The Link
6(3)
Standardized Methods
8(1)
Episode 4: The Form and the Redirect
9(1)
Application State
10(1)
Resource State
11(2)
Connectedness
13(1)
The Web Is Something Special
14(1)
Web APIs Lag Behind the Web
15(1)
The Semantic Challenge
16(1)
2 A Simple API 17(12)
HTTP GET: Your Safe Bet
18(1)
How to Read an HTTP Response
18(2)
JSON
20(1)
Collection+JSON
21(1)
Writing to an API
22(2)
HTTP POST: How Resources Are Born
24(1)
Liberated by Constraints
25(2)
Application Semantics Create the Semantic Gap
27(2)
3 Resources and Representations 29(16)
A Resource Can Be Anything
30(1)
A Representation Describes Resource State
30(1)
Representations Are Transferred Back and Forth
31(1)
Resources with Many Representations
32(1)
The Protocol Semantics of HTTP
33(9)
GET
34(1)
DELETE
35(1)
Idempotence
36(1)
POST-to-Append
37(1)
PUT
37(1)
PATCH
38(1)
LINK and UNLINK
39(1)
HEAD
40(1)
OPTIONS
40(1)
Overloaded POST
41(1)
Which Methods Should You Use?
42(3)
4 Hypermedia 45(14)
HTML as a Hypermedia Format
46(3)
URI Templates
49(1)
URI Versus URL
50(1)
The Link Header
51(1)
What Hypermedia Is For
52(3)
Guiding the Request
52(1)
Promises About the Response
53(1)
Workflow Control
54(1)
Beware of Fake Hypermedia!
55(1)
The Semantic Challenge: How Are We Doing?
56(3)
5 Domain-Specific Designs 59(32)
Maze+XML: A Domain-Specific Design
60(1)
How Maze+XML Works
61(4)
Link Relations
62(2)
Follow a Link to Change Application State
64(1)
The Collection of Mazes
65(2)
Is Maze+XML an API?
67(1)
Client #1: The Game
68(4)
A Maze+XML Server
72(2)
Client #2: The Mapmaker
74(2)
Client #3: Tie Roaster
76(1)
Clients Do the Job They Want to Do
77(1)
Extending a Standard
77(3)
The Mapmaker's Flaw
80(3)
The Fix (and the Flaw in the Fix)
81(2)
Maze as Metaphor
83(1)
Meeting the Semantic Challenge
83(1)
Where Are the Domain-Specific Designs?
83(3)
The Prize at the End
84(1)
Hypermedia in the Headers
84(1)
Steal the Application Semantics
84(2)
If You Can't Find a Domain-Specific Design, Don't Make One
86(1)
Kinds of API Clients
86(5)
Human-Driven Clients
86(1)
Automated Clients
87(4)
6 The Collection Pattern 91(18)
What's a Collection?
93(1)
Collections Link to Items
93(1)
Collection+JSON
94(6)
Representing the Items
95(3)
The Write Template
98(1)
Search Templates
99(1)
How a (Generic) Collection Works
100(2)
GET
100(1)
POST-to-Append
100(1)
PUT and PATCH
101(1)
DELETE
101(1)
Pagination
101(1)
Search Forms
102(1)
The Atom Publishing Protocol (AtomPub)
102(4)
AtomPub Plug-in Standards
104(1)
Why Doesn't Everyone Use AtomPub?
105(1)
The Semantic Challenge: How Are We Doing?
106(3)
7 Pure-Hypermedia Designs 109(24)
Why HTML?
109(1)
HTML's Capabilities
110(3)
Hypermedia Controls
110(1)
Plug-in Application Semantics
111(2)
Microformats
113(1)
The hMaze Microformat
114(2)
Microdata
116(1)
Changing Resource State
117(5)
Adding Application Semantics to Forms
119(3)
The Alternative to Hypermedia Is Media
122(2)
HTMEs Limits
124(1)
HTML 5 to the Rescue?
124(1)
The Hypertext Application Language
125(4)
Siren
129(1)
The Semantic Challenge: How Are We Doing?
130(3)
8 Profiles 133(24)
How Does A Client Find the Documentation?
134(1)
What's a Profile?
135(1)
Linking to a Profile
135(2)
The profile Link Relation
135(1)
The profile Media Type Parameter
136(1)
Special-Purpose Hypermedia Controls
136(1)
Profiles Describe Protocol Semantics
137(1)
Profiles Describe Application Semantics
138(3)
Link Relations
138(1)
Unsafe Link Relations
139(1)
Semantic Descriptors
140(1)
XMDP: The First Machine-Readable Profile Format
141(2)
ALPS
143(7)
Advantages of ALPS
148(2)
ALPS Doesn't Do Everything
150(1)
JSON-LD
150(4)
Embedded Documentation
154(1)
In Summary
155(2)
9 The Design Procedure 157(42)
Two-Step Design Procedure
157(1)
Seven-Step Design Procedure
158(15)
Step 1: List the Semantic Descriptors
159(2)
Step 2: Draw a State Diagram
161(3)
Step 3: Reconcile Names
164(3)
Step 4: Choose a Media Type
167(2)
Step 5: Write a Profile
169(1)
Step 6: Implementation
169(1)
Step 7: Publication
170(3)
Example: You Type It, We Post It
173(4)
List the Semantic Descriptors
173(1)
Draw a State Diagram
174(1)
Reconcile Names
174(1)
Choose a Media Type
175(1)
Write a Profile
176(1)
Some Design Advice
177(13)
Resources Are Implementation Details
177(1)
Don't Fall into the Collection Trap
178(1)
Don't Start with the Representation Format
179(1)
URL Design Doesn't Matter
180(2)
Standard Names Are Probably Better Than Your Names
182(1)
If You Design a Media Type
183(2)
When Your API Changes
185(4)
Don't Keep All the Hypermedia in One Place
189(1)
Adding Hypermedia to an Existing API
190(2)
Fixing Up an XML-Based API
191(1)
Is It Worth It?
192(1)
Alice's Second Adventure
192(7)
Episode 1: The Nonsense Representation
192(2)
Episode 2: The Profile
194(2)
Alice Figured It Out
196(3)
10 The Hypermedia Zoo 199(38)
Domain-Specific Formats
200(6)
Maze+XML
200(1)
OpenSearch
201(1)
Problem Detail Documents
201(1)
SVG
202(2)
VoiceXML
204(2)
Collection Pattern Formats
206(9)
Collection+JSON
206(1)
The Atom Publishing Protocol
207(1)
OData
208(7)
Pure Hypermedia Formats
215(10)
HTML
216(1)
HAL
216(1)
Siren
217(1)
The Link Header
218(1)
The Location and Content-Location Headers
218(1)
URL Lists
219(1)
JSON Home Documents
219(1)
The Link-Template Header
220(1)
WADL
221(1)
XLink
222(2)
XForms
224(1)
GeoJSON: A Troubled Type
225(5)
GeoJSON Has No Generic Hypermedia Controls
226(2)
GeoJSON Has No Media Type
228(1)
Learning from GeoJSON
229(1)
The Semantic Zoo
230(7)
The TANA Registry of Link Relations
230(1)
The Microformats Wild
231(2)
Link Relations from the Microformats Wild
233(1)
schema.org
233(1)
Dublin Core
234(1)
Activity Streams
235(1)
The ALPS Registry
235(2)
11 HTTP for APIs 237(26)
The New HTTP/1.1 Specification
238(1)
Response Codes
238(1)
Headers
238(1)
Choosing Between Representations
239(2)
Content Negotiation
239(1)
Hypermedia Menus
240(1)
The Canonical URL
241(1)
HTTP Performance
241(7)
Caching
241(1)
Conditional GET
242(2)
Look-Before-You-Leap Requests
244(1)
Compression
245(1)
Partial GET
246(1)
Pipelining
247(1)
Avoiding the Lost Update Problem
248(1)
Authentication
249(8)
The WWW-Authenticate and Authorization Headers
250(1)
Basic Auth
251(1)
OAuth 1.0
252(3)
Where OAuth 1.0 Falls Short
255(1)
OAuth 2.0
256(1)
When to Give Up on OAuth
256(1)
Extensions to HTTP
257(3)
The PATCH Method
257(1)
The LINK and UNLINK Methods
258(1)
WebDAV
259(1)
HTTP 2.0
260(3)
12 Resource Description and Linked Data 263(26)
RDF
264(3)
RDF Treats URLs as URIs
265(2)
When to Use the Description Strategy
267(2)
Resource Types
269(1)
RDF Schema
270(2)
The Linked Data Movement
272(2)
JSON-LD
274(2)
JSON-LD as a Representation Format
275(1)
Hydra
276(4)
The XRD Family
280(4)
XRD and JRD
281(1)
Web Host Metadata Documents
282(1)
WebFinger
283(1)
The Ontology Zoo
284(2)
schema.org RDF
285(1)
FOAF
285(1)
vocab.org
286(1)
Conclusion: The Description Strategy Lives!
286(3)
13 CoAP: REST for Embedded Systems 289(8)
A CoAP Request
290(1)
A CoAP Response
290(1)
Kinds of Messages
291(1)
Delayed Response
292(1)
Multicast Messages
293(1)
The CoRE Link Format
293(2)
Conclusion: REST Without HTTP
295(2)
A The Status Codex 297(22)
B The Header Codex 319(24)
C An API Designer's Guide to the Fielding Dissertation 343(16)
Glossary 359(4)
Index 363
Leonard Richardson (http://www.crummy.com/) is the author of the Ruby Cookbook (O'Reilly) and of several open source libraries, including Beautiful Soup. A California native, he currently lives in New York. An internationally known author and lecturer, Mike Amundsen travels throughout the United States and Europe consulting and speaking on a wide range of topics including distributed network architecture, Web application development, Cloud computing, and other subjects. His recent work focuses on the role hypermedia plays in creating and maintaining applications that can successfully evolve over time. He has more than a dozen books to his credit and recently contributed to the book "RESTful Web Services Cookbook" (by Subbu Allamaraju). When he is not working, Mike enjoys spending time with his family in Kentucky, USA Sam Ruby is a prominent software developer who is a co-chair of the W3C HTML Working Group and has made significant contributions to many of the Apache Software Foundation's open source software projects. He is a Senior Technical Staff Member in the Emerging Technologies Group of IBM.