Jekyll cms site for restcookbook.com

  • By Rest Cookbook
  • Last update: Dec 27, 2022
  • Comments: 11

Contributing to the REST cookbook

The REST cookbook website uses Jekyll, a simple yet powerful blog engine that easily allows for creating simple websites like these.

Contributing to our site is simple:

  • Fork the website to your own github account.
  • Clone your repository onto your computer. Make sure you create a new branch, and not use the master branch.
  • Create a new page inside the /_posts/* directory. This HAS GOT TO BE IN THE FORMAT OF YEAR-MONTH-DAY-FILENAME.html!!!
  • Add and commit your changes, and push it to your repository.
  • Create a pull request and we will try and merge your recipe.

Creating a new page

As said, a page must be placed in the _post directory, and in the year-month-day-filename.html format. Otherwise it wont get picked up by the system. Every post should look somewhat like this:

---
layout: recipe
title: <Title>
category: <Category>
author: <your name>
author_email: <your email address>
---
<h2>Title</h2>

<p>Your recipe</p>

The author_email address is optional. Make sure the category name is one of the existing category names (case matters), otherwise your posting will be added inside a new topic. If you have troubles creating a new page, take a look at one of the existing pages, or ask us for help.

Regenerating a new site

There are two ways to display your new site:

Run as a standalone webserver:

  • Start jekyll in your repository root with: jekyll server
  • Browse to http://:4000 to see your site

Run inside an existing webserver:

  • Make sure your use the _site directory as your document root

When you make changes, you need to regenerate your website. This can be done by running jekyll without any parameters. This regenerates the _site directory.

Github

https://github.com/restcookbook/restcookbook

Comments(11)

  • 1

    first redesign with twitter bootstrap

    as a starting point, i moved the navigation on top and changed the base font family with the Open Sans. it would be great to have it even more defined and customized as soon as new contents are submitted.

    hope you like it.

  • 2

    twitter bootstrap

    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.

  • 3

    Switch POST and PUT in the first paragraph

    As per comment placed on previous commit:

    Since POST is usually used for creating a resource and PUT for updating, in the context of this paragraph they should be placed the other way around. The author is trying to say that both methods can sometimes be used in a mixed fashion.

  • 4

    Will u a add a license to the book?

    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.

  • 5

    Incorrect capitalization of Content-Type header

    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.

  • 6

    Isn't PATCH idempotent?

    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?

  • 7

    Update 2012-12-14-richardsonmaturitymodel.html

    Cleaned up the page a bit and some confusion around HTTP as a transport protocol (it's an application protocol that, at level 0, can be used like a transport protocol).

  • 8

    PATCH is said to be and not be idempotent

    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.

  • 9

    Alternative to the the definition of an idempotent HTTP method according to the spec

    GET is idempotent though retrieved data can be different to the same resource. It's about the intended effect (in that case, to get the representation of a resource) regardless of the retrieved data in that representation. Talking about "the result" can be misunderstood.

    Specification: https://tools.ietf.org/html/rfc7231#section-4.2.2

    I hope this contribution is useful for you, @jaytaph.

    Thanks!

  • 10

    Possible mistake in put-vs-post

    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.

  • 11

    the use of the Location header with HTTP 202 is not actually supported

    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.

Popular Tag

Related