restcookbook / restcookbook Goto Github PK

hi guys,
why don't use twitter bootstrap as main css? i'm available to help substituting (or adding alongside) bootstrap to the current jekill implementation.
what do you think?

thanks for having released this great project.

Instead of just simple header snippets, make sure that the examples have all the details like correct headers etc.

Should "...communication so servers are not.." be "...communication so clients are not..." ?

The button is visible but is not clickable as it's situated under the "The RESTful CookBook" title.

The current example is not a diff, and there's no other mention of this property on the page.

I'd suggest setting the link in the repository settings (or README) to the main website ;)

A file called LICENSE or COPYING in the repo root is customary.

Hi,

I stumbled upon this site: http://restcookbook.com/Resources/asynchroneous-operations/ saying:

HTTP/1.1 202 Accepted
Location: /queue/12345

This location can store information about the status of the actual resource: an ETA on when it will be created, what is currently being done or processed.

Apparently, this is not true, as things like PHP enforce a different interpretation of RFC 2616 with regard to the Location header, cf.

https://bugs.php.net/bug.php?id=70273
https://bugs.php.net/bug.php?id=74535

Please fix this suggestion to avoid recommending Location then. TIA.

It would be really cool, having a downloadable epub ebook, to read this nice book offline on my reader.

there is a jekyll extension for that (havn't tested it):

https://github.com/glejeune/jekyll-epub

http://restcookbook.com/HTTP%20Methods/put-vs-post/ says:

Use PUT when you can update a resource completely through a specific resource.

did you mean:

Use PUT when you can update a resource completely through a specific location.

In the "When should we use the PATCH HTTP method?" page, the content of the page say PATCH is idempotent as it will always change the same object in the same way.

In the caveat section, the PATCH is neither safe nor idempotent. Which is contradicting the previous info. The page on what method are safe or idempotent also say PATCH isn't idempotent.

On http://restcookbook.com/Resources/using-custom-content-types/ the Content-Type header is capitalized as 'Content-type'. I fixed this with pull request #72.

According to the "Overview of (some) HTTP-Methods" table in "What are idempotent and/or safe methods?", PATCH is not idempotent. As far as I understood it should be since, repeating the same PATCH call over and over should result in the same response. Or did I miss something there?

... dont use a self signed certificate.....

Words

More information about HATEOAS can be found below.

look at least misleading

None of the links on the homepage are opening or navigating to the heading. Please look into it

Hi Joshua. It's a good read to start with REST API, and i would love to translate it into Chinese. Only for the purpose to spread it as an open-source book. I'm wondering if i need any kind of permission.

One of the principles of REST, AFAIK, is that Nouns are good, Verbs are bad. This is intuitive as, in REST, a resource is supposed to be a representation of an element, and not a process. The verbs, on the other hands, are provided by the uniform interface that is defined by the RESTful API, and that is agreed upon by both the server and the client (see section 5.1.5 of Fielding's dissertation). In the case of a web API using HTML, the verbs would namely be the HTTP methods.

This constraint seems to be violated in the examples in the HATEAOS post:

<link rel="deposit" href="/account/12345/deposit" />
<link rel="withdraw" href="/account/12345/withdraw" />
<link rel="transfer" href="/account/12345/transfer" />
<link rel="close" href="/account/12345/close" />

I propose changing withdraw to withdrawal. deposit and transfer remain unchanged but it could be indicated that they refer to nouns, not verbs. The actions withdraw, transfer, and deposit would be equivalent to doing a POST on the corresponding resource. The resources could then be accessed with GET calls.

As for closing the account, this would be handled in a RESTful API using a closed flag within the account attributes. Closing an account would be equivalent to a PUT setting this flag. To prevent closing accounts that are in the red, the API would forbid PUT operations on that account until it is in the green again (and the user can know what options are available by issuing an OPTIONS request to the URI of the account). I don't think this particular feature should be kept in this post as it is not tied to the concept of HATEAOS.