<a href="http://restcookbook.com/Resources/pagination/" rel="nofollow">http://restcookbook.com/Resources/pagination/</a><p><pre><code> "Even though it's tempting to create your own pagination scheme by "building"
URLs, you should only use the information given by the API. This means, you
cannot assume that the 3rd page can be found at /collection/3. If you do,
your client will break as soon as the API changes its pagination behaviour."
</code></pre>
Is that a legitimate caveat?<p>Are there clients that don't break when you change the API the client works with? Pretty smart clients.
Cool idea.
But it doesn't seem to be finished. Here's an example: <a href="http://restcookbook.com/Basics/loggingin/" rel="nofollow">http://restcookbook.com/Basics/loggingin/</a><p>Maybe it wasn't the author that submitted this? Or is the author asking for some help?
<a href="http://restcookbook.com/Basics/hateoas/" rel="nofollow">http://restcookbook.com/Basics/hateoas/</a> - What is HATEOAS and why is it important for my REST API?<p>This page doesn't even try to explain why HATEOAS is important. And I'm not sure that it is.<p>This example uses some arbitrary xml to describe the API, but if no client can consistently read and understand it, what purpose does it serve?
Many examples do not comply to HTTP standard at all, they're just schematic sketches. I mean, required headers are missing, response bodies are not separated from headers and so on.<p>I believe, examples must be as real-world as possible. Say, the PATCH example must add at least an Content-Type header (and probably use RFC5261), otherwise an important aspect's lost.