Muutke küpsiste eelistusi

REST API Design Rulebook [Pehme köide]

3.35/5 (323 hinnangut Goodreads-ist)
  • Formaat: Paperback / softback, 114 pages
  • Ilmumisaeg: 29-Nov-2011
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1449310508
  • ISBN-13: 9781449310509
Teised raamatud teemal:
  • Pehme köide
  • Hind: 25,32 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Tavahind: 29,79 €
  • 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
REST API Design RulebookSuurem pilt
  • Formaat: Paperback / softback, 114 pages
  • Ilmumisaeg: 29-Nov-2011
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1449310508
  • ISBN-13: 9781449310509
Teised raamatud teemal:
Püsilink: https://www.kriso.ee/db/9781449310509.html
Märksõnad:

In today’s market, where rival web services compete for attention, a well-designed REST API is a must-have feature. This concise book presents a set of API design rules, drawn primarily from best practices that stick close to the Web’s REST architectural style. Along with rules for URI design and HTTP use, you’ll learn guidelines for media types and representational forms.

REST APIs are ubiquitous, but few of them follow a consistent design methodology. Using these simple rules, you will design web service APIs that adhere to recognized web standards. To assist you, author Mark Massé introduces the Web Resource Modeling Language (WRML), a conceptual framework he created for the design and implementation of REST APIs.

  • Learn design rules for addressing resources with URIs
  • Apply design principles to HTTP’s request methods and response status codes
  • Work with guidelines for conveying metadata through HTTP headers and media types
  • Get design tips to address the needs of client programs, including the special needs of browser-based JavaScript clients
  • Understand why REST APIs should be designed and configured, not coded
Preface ix
1 Introduction
1(10)
Hello World Wide Web
1(1)
Web Architecture
2(3)
Client-Server
3(1)
Uniform Interface
3(1)
Layered System
4(1)
Cache
4(1)
Stateless
4(1)
Code-On-Demand
4(1)
Web Standards
5(1)
REST
5(1)
REST APIs
5(1)
REST API Design
6(1)
Rules
6(1)
WRML
7(1)
Recap
7(4)
2 Identifier Design with URIs
11(12)
URIs
11(1)
URI Format
11(3)
Rule: Forward slash separator (/) must be used to indicate a hierarchical relationship
12(1)
Rule: A trailing forward slash (/) should not be included in URIs
12(1)
Rule: Hyphens (-) should be used to improve the readability of URIs
12(1)
Rule: Underscores (_) should not be used in URIs
12(1)
Rule: Lowercase letters should be preferred in URI paths
13(1)
Rule: File extensions should not be included in URIs
13(1)
URI Authority Design
14(1)
Rule: Consistent subdomain names should be used for your APIs
14(1)
Rule: Consistent subdomain names should be used for your client developer portal
14(1)
Resource Modeling
14(1)
Resource Archetypes
15(1)
Document
15(1)
Collection
15(1)
Store
16(1)
Controller
16(1)
URI Path Design
16(3)
Rule: A singular noun should be used for document names
17(1)
Rule: A plural noun should be used for collection names
17(1)
Rule: A plural noun should be used for store names
17(1)
Rule: A verb or verb phrase should be used for controller names
17(1)
Rule: Variable path segments may be substituted with identity-based values
18(1)
Rule: CRUD function names should not be used in URIs
18(1)
URI Query Design
19(1)
Rule: The query component of a URI may be used to filter collections or stores
19(1)
Rule: The query component of a URI should be used to paginate collection or store results
20(1)
Recap
20(3)
3 Interaction Design with HTTP
23(12)
HTTP/1.1
23(1)
Request Methods
23(5)
Rule: GET and POST must not be used to tunnel other request methods
24(1)
Rule: GET must be used to retrieve a representation of a resource
24(1)
Rule: HEAD should be used to retrieve response headers
25(1)
Rule: PUT must be used to both insert and update a stored resource
25(1)
Rule: PUT must be used to update mutable resources
26(1)
Rule: POST must be used to create a new resource in a collection
26(1)
Rule: POST must be used to execute controllers
26(1)
Rule: DELETE must be used to remove a resource from its parent
27(1)
Rule: OPTIONS should be used to retrieve metadata that describes a resource's available interactions
27(1)
Response Status Codes
28(5)
Rule: 200 ("OK") should be used to indicate nonspecific success
28(1)
Rule: 200 ("OK") must not be used to communicate errors in the response body
28(1)
Rule: 201 ("Created") must be used to indicate successful resource creation
28(1)
Rule: 202 ("Accepted") must be used to indicate successful start of an asynchronous action
29(1)
Rule: 204 ("No Content") should be used when the response body is intentionally empty
29(1)
Rule: 301 ("Moved Permanently") should be used to relocate resources
29(1)
Rule: 302 ("Found") should not be used
29(1)
Rule: 303 ("See Other") should be used to refer the client to a different URI
30(1)
Rule: 304 ("Not Modified") should be used to preserve bandwidth
30(1)
Rule: 307 ("Temporary Redirect") should be used to tell clients to resubmit the request to another URI
30(1)
Rule: 400 ("Bad Request") may be used to indicate nonspecific failure
30(1)
Rule: 401 ("Unauthorized") must be used when there is a problem with the client's credentials
31(1)
Rule: 403 ("Forbidden") should be used to forbid access regardless of authorization state
31(1)
Rule: 404 ("Not Found") must be used when a client's URI cannot be mapped to a resource
31(1)
Rule: 405 ("Method Not Allowed") must be used when the HTTP method is not supported
31(1)
Rule: 406 ("Not Acceptable") must be used when the requested media type cannot be served
32(1)
Rule: 409 ("Conflict") should be used to indicate a violation of resource state
32(1)
Rule: 412 ("Precondition Failed") should be used to support conditional operations
32(1)
Rule: 415 ("Unsupported Media Type") must be used when the media type of a request's payload cannot be processed
32(1)
Rule: 500 ("Internal Server Error") should be used to indicate API malfunction
32(1)
Recap
33(2)
4 Metadata Design
35(12)
HTTP Headers
35(4)
Rule: Content-Type must be used
35(1)
Rule: Content-Length should be used
35(1)
Rule: Last-Modified should be used in responses
35(1)
Rule: ETag should be used in responses
36(1)
Rule: Stores must support conditional PUT requests
36(1)
Rule: Location must be used to specify the URI of a newly created resource
37(1)
Rule: Cache-Control, Expires, and Date response headers should be used to encourage caching
37(1)
Rule: Cache-Control, Expires, and Pragma response headers may be used to discourage caching
38(1)
Rule: Caching should be encouraged
38(1)
Rule: Expiration caching headers should be used with 200 ("OK") responses
38(1)
Rule: Expiration caching headers may optionally be used with 3xx and 4xx responses
38(1)
Rule: Custom HTTP headers must not be used to change the behavior of HTTP methods
38(1)
Media Types
39(2)
Media Type Syntax
39(1)
Registered Media Types
39(1)
Vendor-Specific Media Types
40(1)
Media Type Design
41(3)
Rule: Application-specific media types should be used
41(2)
Rule: Media type negotiation should be supported when multiple representations are available
43(1)
Rule: Media type selection using a query parameter may be supported
44(1)
Recap
44(3)
5 Representation Design
47(24)
Message Body Format
47(2)
Rule: JSON should be supported for resource representation
47(1)
Rule: JSON must be well-formed
48(1)
Rule: XML and other formats may optionally be used for resource representation
48(1)
Rule: Additional envelopes must not be created
49(1)
Hypermedia Representation
49(7)
Rule: A consistent form should be used to represent links
49(3)
Rule: A consistent form should be used to represent link relations
52(1)
Rule: A consistent form should be used to advertise links
53(1)
Rule: A self link should be included in response message body representations
54(1)
Rule: Minimize the number of advertised "entry point" API URIs
54(1)
Rule: Links should be used to advertise a resource's available actions in a state-sensitive manner
55(1)
Media Type Representation
56(12)
Rule: A consistent form should be used to represent media type formats
56(3)
Rule: A consistent form should be used to represent media type schemas
59(9)
Error Representation
68(2)
Rule: A consistent form should be used to represent errors
68(1)
Rule: A consistent form should be used to represent error responses
69(1)
Rule: Consistent error types should be used for common error conditions
70(1)
Recap
70(1)
6 Client Concerns
71(14)
Introduction
71(1)
Versioning
71(1)
Rule: New URIs should be used to introduce new concepts
71(1)
Rule: Schemas should be used to manage representational form versions
72(1)
Rule: Entity tags should be used to manage representational state versions
72(1)
Security
72(1)
Rule: OAuth may be used to protect resources
72(1)
Rule: API management solutions may be used to protect resources
73(1)
Response Representation Composition
73(5)
Rule: The query component of a URI should be used to support partial responses
74(2)
Rule: The query component of a URI should be used to embed linked resources
76(2)
Processing Hypermedia
78(1)
JavaScript Clients
79(4)
Rule: JSONP should be supported to provide multi-origin read access from JavaScript
80(2)
Rule: CORS should be supported to provide multi-origin read/write access from JavaScript
82(1)
Recap
83(2)
7 Final Thoughts
85(8)
State of the Art
85(1)
Uniform Implementation
86(5)
Principle: REST API designs differ more than necessary
86(1)
Principle: A REST API should be designed, not coded
87(1)
Principle: Programmers and their organizations benefit from consistency
88(1)
Principle: A REST API should be created using a GUI tool
89(2)
Recap
91(2)
Appendix: My First REST API 93
Mark Masse resides in Seattle, where he is a Senior Director of Engineering at ESPN. Mark has fourteen years of engineering, management, and architecture experience with The Walt Disney Company. He began his career with Starwave creating rich, interactive Java applets for ESPN Sportszone, NFL.com, and NASCAR Online. Mark architected and developed the content management system (CMS) that powers all of the Disney web sites including ESPN.com, ABC.com and Disney.com. In 2008, he received a "Disney Inventor Award" for creating a "System and Method for Determining the Data Model Used to Create a Web Page."