RESTful Web APIs
Leonard Richardson, Sam Ruby, Mike Amundsen
Language: English
Pages: 404
ISBN: 1449358063
Format: PDF / Kindle (mobi) / ePub
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
HTML, XHTML, and CSS: Comprehensive (6th Edition)
Predictive Analytics for Dummies
Web Performance Daybook Volume 2
between them whose link relation is “next.” Perhaps /story/part1 now has a link to /story/part3 with rel="next". These methods aren’t technically necessary. You can duplicate their functionality with PUT. But they simplify things. They split out a common operation—manipulation of the hypermedia links between resources—and give it its own protocol semantics. In Chapter 3, I mentioned that between 1997 and 1999, these methods were a standard part of HTTP. RFC 2616 removed them because it wasn’t
to save the document as. That parameter opens up a can of worms, security-wise, which is why the Content-Disposition header was explicitly excluded from the HTTP standard. When writing a client that respects Content-Disposition, or when allowing API clients to name the files they upload, see the advice in RFC 6266, and please be careful. Content-Encoding Type: Response header. Importance: Medium to high. This response header is the counterpart to the request header Accept-Encoding. The
specification to fully understand the entity-body. This is how a domain-specific design meets the semantic challenge: by defining a document format that represents the problem (such as the layout of a maze), and by registering a media type for that format, so that a client knows right away when it’s encountered an instance of the problem. In general, I don’t recommend creating new domain-specific media types. It’s usually less work to add application semantics to a generic hypermedia format—a
"cell11":{"title":"Laundry Room", "doors":[0,1,1,0]}, "cell12":{"title":"Smoking Room", "doors":[1,0,1,1]}, "cell13":{"title":"Dining Room", "doors":[1,0,0,1]}, "cell14":{"title":"Sitting Room", "doors":[0,1,1,0]}, "cell15":{"title":"Standing Room", "doors":[1,1,1,0]}, "cell16":{"title":"Hobby Room", "doors":[1,0,1,0]}, "cell17":{"title":"Observatory", "doors":[1,1,0,0]}, "cell18":{"title":"Hot House", "doors":[0,1,0,1]}, "cell19":{"title":"Guest Room", "doors":[0,0,1,0]},
when a human is tired of this routine and wants to automate it. The human chooses an API and figures out out which state transitions (for an API that serves hypermedia documents) or API calls (for a hypermedia-ignorant API) are necessary to carry out the routine. Then the human writes an algorithm that automates the process of triggering those state transitions or making those API calls. The Boaster client from earlier in this chapter is a very simple script. It knows about one bit of