Updating Git URLs

GET Method modified

.gitignore

@@ -0,0 +1,2 @@
+public/
+.hugo_build.lock

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "themes/hugo-theme-relearn"]
+	path = themes/hugo-theme-relearn
+	url = https://github.com/McShelby/hugo-theme-relearn.git

.htaccess

@@ -7,3 +7,4 @@ RewriteRule ^(.*)$ http://www.restapitutorial.com/$1 [r=301,nc]
 //301 Redirect Old File
 Redirect 301 http://www.restapitutorial.com/restquicktips.html http://www.restapitutorial.com/lessons/restquicktips.html
 Redirect 301 http://www.restapitutorial.com/httpmethods.html http://www.restapitutorial.com/lessons/httpmethods.html
+Redirect 301 http://www.restapitutorial.com/apiconsulting.html http://www.restapitutorial.com/restapiwebinar.html

.project

@@ -1,17 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<projectDescription>
-	<name>RestApiTutorial</name>
-	<comment></comment>
-	<projects>
-	</projects>
-	<buildSpec>
-		<buildCommand>
-			<name>com.aptana.ide.core.unifiedBuilder</name>
-			<arguments>
-			</arguments>
-		</buildCommand>
-	</buildSpec>
-	<natures>
-		<nature>com.aptana.projects.webnature</nature>
-	</natures>
-</projectDescription>

LICENSE

@@ -0,0 +1,428 @@
+Attribution-ShareAlike 4.0 International
+
+=======================================================================
+
+Creative Commons Corporation ("Creative Commons") is not a law firm and
+does not provide legal services or legal advice. Distribution of
+Creative Commons public licenses does not create a lawyer-client or
+other relationship. Creative Commons makes its licenses and related
+information available on an "as-is" basis. Creative Commons gives no
+warranties regarding its licenses, any material licensed under their
+terms and conditions, or any related information. Creative Commons
+disclaims all liability for damages resulting from their use to the
+fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and
+conditions that creators and other rights holders may use to share
+original works of authorship and other material subject to copyright
+and certain other rights specified in the public license below. The
+following considerations are for informational purposes only, are not
+exhaustive, and do not form part of our licenses.
+
+     Considerations for licensors: Our public licenses are
+     intended for use by those authorized to give the public
+     permission to use material in ways otherwise restricted by
+     copyright and certain other rights. Our licenses are
+     irrevocable. Licensors should read and understand the terms
+     and conditions of the license they choose before applying it.
+     Licensors should also secure all rights necessary before
+     applying our licenses so that the public can reuse the
+     material as expected. Licensors should clearly mark any
+     material not subject to the license. This includes other CC-
+     licensed material, or material used under an exception or
+     limitation to copyright. More considerations for licensors:
+	wiki.creativecommons.org/Considerations_for_licensors
+
+     Considerations for the public: By using one of our public
+     licenses, a licensor grants the public permission to use the
+     licensed material under specified terms and conditions. If
+     the licensor's permission is not necessary for any reason--for
+     example, because of any applicable exception or limitation to
+     copyright--then that use is not regulated by the license. Our
+     licenses grant only permissions under copyright and certain
+     other rights that a licensor has authority to grant. Use of
+     the licensed material may still be restricted for other
+     reasons, including because others have copyright or other
+     rights in the material. A licensor may make special requests,
+     such as asking that all changes be marked or described.
+     Although not required by our licenses, you are encouraged to
+     respect those requests where reasonable. More_considerations
+     for the public:
+	wiki.creativecommons.org/Considerations_for_licensees
+
+=======================================================================
+
+Creative Commons Attribution-ShareAlike 4.0 International Public
+License
+
+By exercising the Licensed Rights (defined below), You accept and agree
+to be bound by the terms and conditions of this Creative Commons
+Attribution-ShareAlike 4.0 International Public License ("Public
+License"). To the extent this Public License may be interpreted as a
+contract, You are granted the Licensed Rights in consideration of Your
+acceptance of these terms and conditions, and the Licensor grants You
+such rights in consideration of benefits the Licensor receives from
+making the Licensed Material available under these terms and
+conditions.
+
+
+Section 1 -- Definitions.
+
+  a. Adapted Material means material subject to Copyright and Similar
+     Rights that is derived from or based upon the Licensed Material
+     and in which the Licensed Material is translated, altered,
+     arranged, transformed, or otherwise modified in a manner requiring
+     permission under the Copyright and Similar Rights held by the
+     Licensor. For purposes of this Public License, where the Licensed
+     Material is a musical work, performance, or sound recording,
+     Adapted Material is always produced where the Licensed Material is
+     synched in timed relation with a moving image.
+
+  b. Adapter's License means the license You apply to Your Copyright
+     and Similar Rights in Your contributions to Adapted Material in
+     accordance with the terms and conditions of this Public License.
+
+  c. BY-SA Compatible License means a license listed at
+     creativecommons.org/compatiblelicenses, approved by Creative
+     Commons as essentially the equivalent of this Public License.
+
+  d. Copyright and Similar Rights means copyright and/or similar rights
+     closely related to copyright including, without limitation,
+     performance, broadcast, sound recording, and Sui Generis Database
+     Rights, without regard to how the rights are labeled or
+     categorized. For purposes of this Public License, the rights
+     specified in Section 2(b)(1)-(2) are not Copyright and Similar
+     Rights.
+
+  e. Effective Technological Measures means those measures that, in the
+     absence of proper authority, may not be circumvented under laws
+     fulfilling obligations under Article 11 of the WIPO Copyright
+     Treaty adopted on December 20, 1996, and/or similar international
+     agreements.
+
+  f. Exceptions and Limitations means fair use, fair dealing, and/or
+     any other exception or limitation to Copyright and Similar Rights
+     that applies to Your use of the Licensed Material.
+
+  g. License Elements means the license attributes listed in the name
+     of a Creative Commons Public License. The License Elements of this
+     Public License are Attribution and ShareAlike.
+
+  h. Licensed Material means the artistic or literary work, database,
+     or other material to which the Licensor applied this Public
+     License.
+
+  i. Licensed Rights means the rights granted to You subject to the
+     terms and conditions of this Public License, which are limited to
+     all Copyright and Similar Rights that apply to Your use of the
+     Licensed Material and that the Licensor has authority to license.
+
+  j. Licensor means the individual(s) or entity(ies) granting rights
+     under this Public License.
+
+  k. Share means to provide material to the public by any means or
+     process that requires permission under the Licensed Rights, such
+     as reproduction, public display, public performance, distribution,
+     dissemination, communication, or importation, and to make material
+     available to the public including in ways that members of the
+     public may access the material from a place and at a time
+     individually chosen by them.
+
+  l. Sui Generis Database Rights means rights other than copyright
+     resulting from Directive 96/9/EC of the European Parliament and of
+     the Council of 11 March 1996 on the legal protection of databases,
+     as amended and/or succeeded, as well as other essentially
+     equivalent rights anywhere in the world.
+
+  m. You means the individual or entity exercising the Licensed Rights
+     under this Public License. Your has a corresponding meaning.
+
+
+Section 2 -- Scope.
+
+  a. License grant.
+
+       1. Subject to the terms and conditions of this Public License,
+          the Licensor hereby grants You a worldwide, royalty-free,
+          non-sublicensable, non-exclusive, irrevocable license to
+          exercise the Licensed Rights in the Licensed Material to:
+
+            a. reproduce and Share the Licensed Material, in whole or
+               in part; and
+
+            b. produce, reproduce, and Share Adapted Material.
+
+       2. Exceptions and Limitations. For the avoidance of doubt, where
+          Exceptions and Limitations apply to Your use, this Public
+          License does not apply, and You do not need to comply with
+          its terms and conditions.
+
+       3. Term. The term of this Public License is specified in Section
+          6(a).
+
+       4. Media and formats; technical modifications allowed. The
+          Licensor authorizes You to exercise the Licensed Rights in
+          all media and formats whether now known or hereafter created,
+          and to make technical modifications necessary to do so. The
+          Licensor waives and/or agrees not to assert any right or
+          authority to forbid You from making technical modifications
+          necessary to exercise the Licensed Rights, including
+          technical modifications necessary to circumvent Effective
+          Technological Measures. For purposes of this Public License,
+          simply making modifications authorized by this Section 2(a)
+          (4) never produces Adapted Material.
+
+       5. Downstream recipients.
+
+            a. Offer from the Licensor -- Licensed Material. Every
+               recipient of the Licensed Material automatically
+               receives an offer from the Licensor to exercise the
+               Licensed Rights under the terms and conditions of this
+               Public License.
+
+            b. Additional offer from the Licensor -- Adapted Material.
+               Every recipient of Adapted Material from You
+               automatically receives an offer from the Licensor to
+               exercise the Licensed Rights in the Adapted Material
+               under the conditions of the Adapter's License You apply.
+
+            c. No downstream restrictions. You may not offer or impose
+               any additional or different terms or conditions on, or
+               apply any Effective Technological Measures to, the
+               Licensed Material if doing so restricts exercise of the
+               Licensed Rights by any recipient of the Licensed
+               Material.
+
+       6. No endorsement. Nothing in this Public License constitutes or
+          may be construed as permission to assert or imply that You
+          are, or that Your use of the Licensed Material is, connected
+          with, or sponsored, endorsed, or granted official status by,
+          the Licensor or others designated to receive attribution as
+          provided in Section 3(a)(1)(A)(i).
+
+  b. Other rights.
+
+       1. Moral rights, such as the right of integrity, are not
+          licensed under this Public License, nor are publicity,
+          privacy, and/or other similar personality rights; however, to
+          the extent possible, the Licensor waives and/or agrees not to
+          assert any such rights held by the Licensor to the limited
+          extent necessary to allow You to exercise the Licensed
+          Rights, but not otherwise.
+
+       2. Patent and trademark rights are not licensed under this
+          Public License.
+
+       3. To the extent possible, the Licensor waives any right to
+          collect royalties from You for the exercise of the Licensed
+          Rights, whether directly or through a collecting society
+          under any voluntary or waivable statutory or compulsory
+          licensing scheme. In all other cases the Licensor expressly
+          reserves any right to collect such royalties.
+
+
+Section 3 -- License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the
+following conditions.
+
+  a. Attribution.
+
+       1. If You Share the Licensed Material (including in modified
+          form), You must:
+
+            a. retain the following if it is supplied by the Licensor
+               with the Licensed Material:
+
+                 i. identification of the creator(s) of the Licensed
+                    Material and any others designated to receive
+                    attribution, in any reasonable manner requested by
+                    the Licensor (including by pseudonym if
+                    designated);
+
+                ii. a copyright notice;
+
+               iii. a notice that refers to this Public License;
+
+                iv. a notice that refers to the disclaimer of
+                    warranties;
+
+                 v. a URI or hyperlink to the Licensed Material to the
+                    extent reasonably practicable;
+
+            b. indicate if You modified the Licensed Material and
+               retain an indication of any previous modifications; and
+
+            c. indicate the Licensed Material is licensed under this
+               Public License, and include the text of, or the URI or
+               hyperlink to, this Public License.
+
+       2. You may satisfy the conditions in Section 3(a)(1) in any
+          reasonable manner based on the medium, means, and context in
+          which You Share the Licensed Material. For example, it may be
+          reasonable to satisfy the conditions by providing a URI or
+          hyperlink to a resource that includes the required
+          information.
+
+       3. If requested by the Licensor, You must remove any of the
+          information required by Section 3(a)(1)(A) to the extent
+          reasonably practicable.
+
+  b. ShareAlike.
+
+     In addition to the conditions in Section 3(a), if You Share
+     Adapted Material You produce, the following conditions also apply.
+
+       1. The Adapter's License You apply must be a Creative Commons
+          license with the same License Elements, this version or
+          later, or a BY-SA Compatible License.
+
+       2. You must include the text of, or the URI or hyperlink to, the
+          Adapter's License You apply. You may satisfy this condition
+          in any reasonable manner based on the medium, means, and
+          context in which You Share Adapted Material.
+
+       3. You may not offer or impose any additional or different terms
+          or conditions on, or apply any Effective Technological
+          Measures to, Adapted Material that restrict exercise of the
+          rights granted under the Adapter's License You apply.
+
+
+Section 4 -- Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that
+apply to Your use of the Licensed Material:
+
+  a. for the avoidance of doubt, Section 2(a)(1) grants You the right
+     to extract, reuse, reproduce, and Share all or a substantial
+     portion of the contents of the database;
+
+  b. if You include all or a substantial portion of the database
+     contents in a database in which You have Sui Generis Database
+     Rights, then the database in which You have Sui Generis Database
+     Rights (but not its individual contents) is Adapted Material,
+
+     including for purposes of Section 3(b); and
+  c. You must comply with the conditions in Section 3(a) if You Share
+     all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not
+replace Your obligations under this Public License where the Licensed
+Rights include other Copyright and Similar Rights.
+
+
+Section 5 -- Disclaimer of Warranties and Limitation of Liability.
+
+  a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
+     EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
+     AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
+     ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
+     IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
+     WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
+     PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
+     ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
+     KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
+     ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
+
+  b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
+     TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
+     NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
+     INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
+     COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
+     USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
+     ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
+     DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
+     IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
+
+  c. The disclaimer of warranties and limitation of liability provided
+     above shall be interpreted in a manner that, to the extent
+     possible, most closely approximates an absolute disclaimer and
+     waiver of all liability.
+
+
+Section 6 -- Term and Termination.
+
+  a. This Public License applies for the term of the Copyright and
+     Similar Rights licensed here. However, if You fail to comply with
+     this Public License, then Your rights under this Public License
+     terminate automatically.
+
+  b. Where Your right to use the Licensed Material has terminated under
+     Section 6(a), it reinstates:
+
+       1. automatically as of the date the violation is cured, provided
+          it is cured within 30 days of Your discovery of the
+          violation; or
+
+       2. upon express reinstatement by the Licensor.
+
+     For the avoidance of doubt, this Section 6(b) does not affect any
+     right the Licensor may have to seek remedies for Your violations
+     of this Public License.
+
+  c. For the avoidance of doubt, the Licensor may also offer the
+     Licensed Material under separate terms or conditions or stop
+     distributing the Licensed Material at any time; however, doing so
+     will not terminate this Public License.
+
+  d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
+     License.
+
+
+Section 7 -- Other Terms and Conditions.
+
+  a. The Licensor shall not be bound by any additional or different
+     terms or conditions communicated by You unless expressly agreed.
+
+  b. Any arrangements, understandings, or agreements regarding the
+     Licensed Material not stated herein are separate from and
+     independent of the terms and conditions of this Public License.
+
+
+Section 8 -- Interpretation.
+
+  a. For the avoidance of doubt, this Public License does not, and
+     shall not be interpreted to, reduce, limit, restrict, or impose
+     conditions on any use of the Licensed Material that could lawfully
+     be made without permission under this Public License.
+
+  b. To the extent possible, if any provision of this Public License is
+     deemed unenforceable, it shall be automatically reformed to the
+     minimum extent necessary to make it enforceable. If the provision
+     cannot be reformed, it shall be severed from this Public License
+     without affecting the enforceability of the remaining terms and
+     conditions.
+
+  c. No term or condition of this Public License will be waived and no
+     failure to comply consented to unless expressly agreed to by the
+     Licensor.
+
+  d. Nothing in this Public License constitutes or may be interpreted
+     as a limitation upon, or waiver of, any privileges and immunities
+     that apply to the Licensor or You, including from the legal
+     processes of any jurisdiction or authority.
+
+
+=======================================================================
+
+Creative Commons is not a party to its public
+licenses. Notwithstanding, Creative Commons may elect to apply one of
+its public licenses to material it publishes and in those instances
+will be considered the “Licensor.” The text of the Creative Commons
+public licenses is dedicated to the public domain under the CC0 Public
+Domain Dedication. Except for the limited purpose of indicating that
+material is shared under a Creative Commons public license or as
+otherwise permitted by the Creative Commons policies published at
+creativecommons.org/policies, Creative Commons does not authorize the
+use of the trademark "Creative Commons" or any other trademark or logo
+of Creative Commons without its prior written consent including,
+without limitation, in connection with any unauthorized modifications
+to any of its public licenses or any other arrangements,
+understandings, or agreements concerning use of licensed material. For
+the avoidance of doubt, this paragraph does not form part of the
+public licenses.
+
+Creative Commons may be contacted at creativecommons.org.
+

README.md

@@ -1,3 +1,7 @@
-HTML source code for www.RestApiTutorial.com along with the Aptana Studio project file(s).
+HTML source code for www.RestApiTutorial.com.
 
 Also includes the PDF, ePub and Mobi (Kindle) versions of the associated RESTful Best Practices document.  In addition, the Libre/Open Office version of the source document is included in the 'media' directory.
+
+![alt Creative Commons License](http://i.creativecommons.org/l/by-sa/4.0/88x31.png)
+
+This work by <a xmlns:cc="http://creativecommons.org/ns#" href="http://www.restapitutorial.com/" property="cc:attributionName" rel="cc:attributionURL">RestApiTutorial.com</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.

ads.txt

@@ -0,0 +1 @@
+google.com, pub-2093481943685202, DIRECT, f08c47fec0942fa0

archetypes/default.md

@@ -0,0 +1,6 @@
+---
+title: "{{ replace .Name "-" " " | title }}"
+date: {{ .Date }}
+draft: true
+---
+

config.toml

@@ -0,0 +1,30 @@
+baseURL = 'http://restapitutorial.com/'
+languageCode = 'en-us'
+title = 'REST API Tutorial'
+uglyURLs = true
+#
+# Change the default theme to hugo-theme-relearn
+theme = "hugo-theme-relearn"
+
+# For search functionality
+[outputs]
+home = [ "HTML", "RSS", "JSON"]
+
+[[menu.shortcuts]]
+name = "<i class='fab fa-fw fa-github'></i> GitHub repo"
+identifier = "ds"
+url = "https://github.com/tfredrich/RestApiTutorial.com"
+weight = 10
+
+[[menu.shortcuts]]
+name = "<i class='fas fa-fw fa-tags'></i> Tags"
+url = "tags/"
+weight = 40
+
+[params]
+  editURL = "https://github.com/tfredrich/RestApiTutorial.com/edit/hugo-refactor/content/"
+  description = "Learn REST API Design"
+  author = "Todd Fredrich"
+  collapsibleMenu = true
+  titleSeparator = " - "
+  themeVariant = [ "relearn-light", "relearn-dark" ]

content/_index.md

@@ -0,0 +1,11 @@
+# Learn REST API Design
+
+Keyword-rich introductory content goes here.
+
+## Get Started
+
+1. Click the arrow in the upper-right corner to progress to the next section or
+1. Begin with [Part 1. The Basics](/basics.html)
+1. Use the left-hand navigation menu to choose a topic.
+1. Use the hamburger menu to open the table of contents for the displayed page.
+

content/advanced/_index.md

@@ -0,0 +1,11 @@
++++
+chapter = true
+pre = "<b>2. </b>"
+title = "Advanced API Design"
+weight = 10
++++
+
+### Part 2
+
+# The Seven Pillars of API Design
+Stay Tuned as We Begin Our Journey in Designing Exquisite RESTful APIs.

content/basics/_index.md

@@ -0,0 +1,16 @@
++++
+chapter = true
+pre = "<b>1. </b>"
+title = "The Basics"
+weight = 5
++++
+
+### Part 1
+
+# Learn REST API Basics
+Quickly learn the basics of what REST is and the core concepts behind it.
+
+{{% notice tip "Here's a Quick Tip!" %}}
+Be on the lookout for Quick Tips in boxes like this throughout the course. They'll provide a jump-start to your super-powers
+(or at least give you a leg up on getting your job done)!
+{{% /notice %}}

content/basics/httpmethods.md

@@ -0,0 +1,85 @@
+---
+title: "HTTP Methods"
+date: 2022-06-07T16:31:51-06:00
+weight: 30
+---
+The HTTP verbs (or methods, as they are formally called) comprise a major portion of our “uniform interface” constraint and provide us the action counterpart to the noun-based resource. The primary or most-commonly-used HTTP verbs are POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations, respectively. There are a number of other verbs, too, but are utilized less frequently. Of those less-frequent methods, OPTIONS and HEAD are used more often than others.
+
+## Overview
+Below is a table summarizing recommended return values of the primary HTTP methods in combination with the resource URIs:
+
+| Method | CRUD | Entire Collection (e.g. /customers) | Specific Item (e.g. /customers/{id}) |
+| --------- | ---- | ----------------------------------- | ------------------------------------ |
+| POST      | Create | 201 (Created), 'Location' header with link to /customers/{id} containing new ID. | 404 (Not Found), 409 (Conflict) if resource already exists. |
+| GET       | Read | 200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists. | 200 (OK), single customer. 404 (Not Found), if ID not found or invalid. |
+| PUT       | Update/Replace | 405 (Method Not Allowed), unless you want to update/replace every resource in the entire collection. | 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. |
+| PATCH     | Update/Modify | 405 (Method Not Allowed), unless you want to modify the collection itself. Which is possible if operating on the collection as a whole. | 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. |
+| DELETE    | Delete | 405 (Method Not Allowed), unless you want to delete the whole collection—not often desirable. | 200 (OK). 404 (Not Found), if ID not found or invalid. |
+
+Below is a more-detailed discussion of the main HTTP methods.
+## POST
+The POST verb is most-often utilized to *create* new a resource. In particular, it's used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. In other words, when creating a new resource, POST to the parent and the service takes care of associating the new resource with the parent, assigning an ID (new resource URI), etc.
+
+On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.
+
+POST is neither safe nor idempotent. It is therefore recommended for non-idempotent resource requests. Making two identical POST requests will most-likely result in two resources containing the same information.
+
+__Examples:__
+* POST http://www.example.com/customers
+* POST http://www.example.com/customers/12345/orders
+
+## GET
+The HTTP GET method is used to **read** (or retrieve) a representation of a resource. In the “happy” (or non-error) path, GET returns a representation in XML or JSON and an HTTP response code of 200 (OK). In an error case, it most often returns a 404 (NOT FOUND) or 400 (BAD REQUEST).
+
+According to the design of the HTTP specification, GET (along with HEAD) requests are used only to read data and not change it. Therefore, when used this way, they are considered safe. That is, they can be called without risk of data modification or corruption—calling it once has the same effect as calling it 10 times, or none at all. Additionally, GET (and HEAD) is idempotent, which means that making multiple identical requests ends up having the same result as a single request.
+
+Do not expose unsafe operations via GET—it should never modify any resources on the server.
+
+__Examples:__
+* GET http://www.example.com/customers/12345
+* GET http://www.example.com/customers/12345/orders
+* GET http://www.example.com/buckets/sample
+
+## PUT
+PUT is most-often utilized for *update* capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource.
+
+However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server. In other words, if the PUT is to a URI that contains the value of a non-existent resource ID. Again, the request body contains a resource representation. Many feel this is convoluted and confusing. Consequently, this method of creation should be used sparingly, if at all.
+
+Alternatively, use POST to create new resources and provide the client-defined ID in the body representation—presumably to a URI that doesn't include the ID of the resource (see POST below).
+
+On successful update, return 200 (or 204 if not returning any content in the body) from a PUT. If using PUT for create, return HTTP status 201 on successful creation. A body in the response is optional—providing one consumes more bandwidth. It is not necessary to return a link via a Location header in the creation case since the client already set the resource ID.
+
+PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent. In other words, if you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call.
+
+If, for instance, calling PUT on a resource increments a counter within the resource, the call is no longer idempotent. Sometimes that happens and it may be enough to document that the call is not idempotent. However, it's recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests.
+
+__Examples:__
+* PUT http://www.example.com/customers/12345
+* PUT http://www.example.com/customers/12345/orders/98765
+* PUT http://www.example.com/buckets/secret_stuff
+
+## PATCH
+PATCH is used for *modify* capabilities. The PATCH request only needs to contain the changes to the resource, not the complete resource.
+
+This resembles PUT, but the body contains a set of instructions describing how a resource currently residing on the server should be modified to produce a new version. This means that the PATCH body should not just be a modified part of the resource, but in some kind of patch language like JSON Patch or XML Patch.
+
+PATCH is neither safe nor idempotent. However, a PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar time frame. Collisions from multiple PATCH requests may be more dangerous than PUT collisions because some patch formats need to operate from a known base-point or else they will corrupt the resource. Clients using this kind of patch application should use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource. For example, the client can use a strong ETag in an If-Match header on the PATCH request.
+
+__Examples:__
+* PATCH http://www.example.com/customers/12345
+* PATCH http://www.example.com/customers/12345/orders/98765
+* PATCH http://www.example.com/buckets/secret_stuff
+
+## DELETE
+DELETE is pretty easy to understand. It is used to *delete* a resource identified by a URI.
+
+On successful deletion, return HTTP status 200 (OK) along with a response body, perhaps the representation of the deleted item (often demands too much bandwidth), or a wrapped response (see Return Values below). Either that or return HTTP status 204 (NO CONTENT) with no response body. In other words, a 204 status with no body, or the JSEND-style response and HTTP status 200 are the recommended responses.
+
+HTTP-spec-wise, DELETE operations are idempotent. If you DELETE a resource, it's removed. Repeatedly calling DELETE on that resource ends up the same: the resource is gone. If calling DELETE say, decrements a counter (within the resource), the DELETE call is no longer idempotent. As mentioned previously, usage statistics and measurements may be updated while still considering the service idempotent as long as no resource data is changed. Using POST for non-idempotent resource requests is recommended.
+
+There is a caveat about DELETE idempotence, however. Calling DELETE on a resource a second time will often return a 404 (NOT FOUND) since it was already removed and therefore is no longer findable. This, by some opinions, makes DELETE operations no longer idempotent, however, the end-state of the resource is the same. Returning a 404 is acceptable and communicates accurately the status of the call.
+
+__Examples:__
+* DELETE http://www.example.com/customers/12345
+* DELETE http://www.example.com/customers/12345/orders
+* DELETE http://www.example.com/bucket/sample

content/basics/idempotence.md

@@ -0,0 +1,14 @@
+---
+title: "Idempotence"
+date: 2022-06-08T15:35:13-06:00
+weight: 50
+---
+{{< youtube 6dVNdFwqeKs >}}
+
+Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition.
+
+From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same (e.g. a resource's state may change between requests).
+
+The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) on subsequent calls, unless the service is configured to "mark" resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next call will not find the resource to delete it and return a 404. However, the state on the server is the same after each DELETE call, but the response is different.
+
+GET, HEAD, OPTIONS and TRACE methods are defined as safe, meaning they are only intended for retrieving data. This makes them idempotent as well since multiple, identical requests will behave the same.

content/basics/resourcenaming.md

@@ -0,0 +1,77 @@
+---
+title: "Resource Naming"
+date: 2022-06-07T16:44:49-06:00
+weight: 40
+---
+In addition to utilizing the HTTP verbs appropriately, resource naming is arguably the most debated and most important concept to grasp when creating an understandable, easily leveraged Web service API. When resources are named well, an API is intuitive and easy to use. Done poorly, that same API can feel klutzy and be difficult to use and understand. Below are a few tips to get you going when creating the resource URIs for your new API.
+
+Essentially, a RESTful API ends up being simply a collection of URIs, HTTP calls to those URIs and some JSON and/or XML representations of resources, many of which will contain relational links. The RESTful principal of addressability is covered by the URIs. Each resource has its own address or URI—every interesting piece of information the server can provide is exposed as a resource. The constraint of uniform interface is partially addressed by the combination of URIs and HTTP verbs, and using them in line with the standards and conventions.
+
+In deciding what resources are within your system, name them as nouns as opposed to verbs or actions. In other words, a RESTful URI should refer to a resource that is a thing instead of referring to an action. Nouns have properties as verbs do not, just another distinguishing factor.
+
+Some example resources are:
+* Users of the system.
+* Courses in which a student is enrolled.
+* A user's timeline of posts.
+* The users that follow another user.
+* An article about horseback riding.
+
+Each resource in a service suite will have at least one URI identifying it. And it's best when that URI makes sense and adequately describes the resource. URIs should follow a predictable, hierarchical structure to enhance understandability and, therefore, usability: predictable in the sense that they're consistent, hierarchical in the sense that data has structure—relationships. This is not a REST rule or constraint, but it enhances the API.
+
+RESTful APIs are written for consumers. The name and structure of URIs should convey meaning to those consumers. It's often difficult to know what the data boundaries should be, but with understanding of your data, you most-likely are equipped to take a stab and what makes sense to return as a representation to your clients. Design for your clients, not for your data.
+
+Let's say we're describing an order system with customers, orders, line items, products, etc. Consider the URIs involved in describing the resources in this service suite:
+
+## Resource URI Examples
+### Customers
+To insert (create) a new customer in the system, we might use:
+* POST http://www.example.com/customers
+
+To read a customer with Customer ID# 33245:
+* GET http://www.example.com/customers/33245
+
+The same URI would be used for PUT and DELETE, to update and delete, respectively.
+
+### Products
+Here are proposed URIs for products:
+*  For creating a new product:
+    * POST http://www.example.com/products
+* For reading, replacing, updating, deleting product ID 66432, respectively:
+    * GET http://www.example.com/products/66432
+    * PUT http://www.example.com/products/66432
+    * PATCH http://www.example.com/products/66432
+    * DELETE http://www.example.com/products/66432
+
+### Orders
+Now, here is where it gets fun... What about creating a new order for a customer? One option might be:
+* POST http://www.example.com/orders
+And that could work to create an order, but it's arguably outside the context of a customer.
+
+Because we want to create an order for a customer (note the relationship), this URI perhaps is not as intuitive as it could be. It could be argued that the following URI would offer better clarity:
+* POST http://www.example.com/customers/33245/orders
+Now we know we're creating an order for customer ID# 33245.
+
+Now what would the following return?
+* GET http://www.example.com/customers/33245/orders
+Probably a list of orders that customer #33245 has created or owns. Note: we may choose to not support DELETE or PUT for that url since it's operating on the entire collection of a cutomer's orders.
+
+Now, to continue the hierarchical concept, what about the following URI?
+* POST http://www.example.com/customers/33245/orders/8769/lineitems
+That might add a line item to order #8769 (which is for customer #33245). Right! GET for that URI might return all the line items for that order. However, if line items don't make sense only in customer context or also make sense outside the context of a customer, we would offer a:
+* POST www.example.com/orders/8769/lineitems URI.
+
+Along those lines, because there may be multiple URIs for a given resource, we might also offer a
+* GET http://www.example.com/orders/8769
+URI that supports retrieving an order by number without having to know the customer number.
+
+To go one layer deeper in the hierarchy:
+* GET http://www.example.com/customers/33245/orders/8769/lineitems/1
+Might return only the first line item in that same order.
+
+By now you can see how the hierarchy concept works. There aren't any hard and fast rules, only make sure the imposed structure makes sense to consumers of your services. As with everything in the craft of Software Development, naming is critical to success.
+
+### Other Example APIs
+Look at some widely used APIs to get the hang of this and leverage the intuition of your teammates to refine your API resource URIs. Some example APIs are:
+* Twitter: https://developer.twitter.com/en/docs/api-reference-index
+* Facebook: https://developers.facebook.com/docs/reference/api/
+* LinkedIn: https://developer.linkedin.com/apis

content/basics/restcontstraints.md

@@ -0,0 +1,55 @@
+---
+title: "The Six Constraints"
+date: 2022-06-07T08:22:06-06:00
+weight: 15
+---
+{{< youtube llpr5924N7E >}}
+
+The REST architectural style describes six constraints. These constraints, applied to the architecture, were originally communicated by Roy Fielding in his doctoral dissertation (see https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) and defines the basis of RESTful-style.
+
+The six constraints are as follows:
+## 1. Uniform Interface
+The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of the uniform interface are:
+
+### 1.a. Resource-Based
+Individual resources are identified in requests using URIs as resource identifiers. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8, depending on the details of the request and the server implementation.
+
+### 1.b. Manipulation of Resources Through Representations
+When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so.
+
+### 1.c. Self-descriptive Messages
+Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cache-ability.
+
+### 1.d. Hypermedia as the Engine of Application State (HATEOAS)
+Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is technically referred-to as hypermedia (or hyperlinks within hypertext).
+
+Aside from the description above, HATEOS also means that, where necessary, links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects. We'll talk about this in more detail later.
+
+The uniform interface that any REST services must provide is fundamental to its design.
+
+## 2. Stateless
+As REST is an acronym for REpresentational State Transfer, statelessness is key. Essentially, what this means is that the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Then after the server does it's processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.
+
+Most of us who have been in the industry for a while are accustomed to programming within a container which provides us with the concept of “session” which maintains state across multiple HTTP requests. In REST, the client must include all information for the server to fulfill the request, resending state as necessary if that state must span multiple requests. Statelessness enables greater scalability since the server does not have to maintain, update or communicate that session state. Additionally, load balancers don't have to worry about session affinity for stateless systems.
+
+So what's the difference between state and a resource? State, or application state, is that which the server cares about to fulfill a request—data necessary for the current session or request. A resource, or resource state, is the data that defines the resource representation—the data stored in the database, for instance. Consider application state to be data that could vary by client, and per request. Resource state, on the other hand, is constant across every client who requests it.
+
+Ever had back-button issues with a web application where it went AWOL at a certain point because it expected you to do things in a certain order? That's because it violated the statelessness principle. There are cases that don't honor the statelessness principle, such as three-legged OAuth, API call rate limiting, etc. However, make every effort to ensure that application state doesn't span multiple requests of your service(s).
+
+## 3. Cacheable
+As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
+
+## 4. Client-Server
+The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.
+
+## 5. Layered System
+A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.
+
+## 6. Code on Demand (optional)
+Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.
+
+Complying with these constraints, and thus conforming to the REST architectural style, will enable any kind of distributed hypermedia system to have desirable emergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability and reliability.
+
+{{% notice info "RESTful or Not?" %}}
+The only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be referred to as RESTful.
+{{% /notice %}}

content/basics/restquicktips.md

@@ -0,0 +1,89 @@
+---
+title: "REST Quick Tips"
+date: 2022-06-06T16:58:56-06:00
+weight: 20
+---
+Whether it's technically RESTful or not (according to the six constraints mentioned previously), here are a few recommended REST-like concepts. These six quick tips will result in better, more usable services.
+
+## Use HTTP Methods to Make Requests Mean Something
+{{% notice tip "Verb-Free URLs" %}}
+API consumers are capable of sending GET, POST, PUT, PATCH and DELETE methods (or verbs), which greatly enhance the clarity of a given request.
+
+Therefore, it is recommended that no verbs (action words) appear in the URL. Instead leverage the HTTP Methods to provide the verb.
+{{% /notice %}}
+
+Generally, the five primary HTTP methods are used as follows:
+
+| Method | Description |
+| ---- | ----------- |
+| GET  | Read a specific resource (by an identifier) or a collection of resources.|
+| PUT  | Replace a specific resource (by an identifier) or a collection of resources. Can also be used to create a specific resource if the resource identifier is known before-hand.|
+| PATCH | Update a specific resource (by an identifier) or a collection of resources. This can be thought of in some ways as a 'partial update' vs the replace that PUT performs.|
+| DELETE | Remove/delete a specific resource by an identifier. |
+| POST | Create a new resource. Also a catch-all verb for operations that don't fit into the other categories. |
+
+{{% notice warning "Safety" %}}
+GET requests MUST not change any underlying resource data. Measurements and tracking which update data may still occur, but the resource identified by the URI MUST not change.
+{{% /notice %}}
+
+## Provide Sensible Resource Names
+{{% notice tip "Art and Science" %}}
+Producing a great API is 80% art and 20% science. Creating a URL hierarchy representing sensible resources is the art part. Having sensible resource names (which are just URL paths, such as /customers/12345/orders) improves the clarity of what a given request does. As humans are involved in understanding an API, this clarity counts.
+{{% /notice %}}
+
+Appropriate resource names provide context for a service request, increasing understandability of the API. Resources are viewed hierarchically via their URI names, offering consumers a friendly, easily-understood hierarchy of resources to leverage in their applications.
+
+Here are some quick-hit rules for URL path (resource name) design:
+* Use identifiers in your URLs instead of in the query-string. Using URL query-string parameters is fantastic for filtering, but not for resource names.
+    * Good: /users/12345
+    * Poor: /api?type=user&id=23
+* Leverage the hierarchical nature of the URL to imply structure.
+* Design for your clients, not for your data.
+* Resource names should be nouns. Avoid verbs as resource names, to improve clarity. Use the HTTP methods to specify the verb portion of the request.
+* Use plurals in URL segments to keep your API URIs consistent across all HTTP methods, using the collection metaphor.
+    * Recommended: /customers/33245/orders/8769/lineitems/1
+    * Not: /customer/33245/order/8769/lineitem/1
+* Avoid using collection verbiage in URLs. For example 'customer_list' as a resource. Use pluralization to indicate the collection metaphor (e.g. customers vs. customer_list).
+* Use lower-case in URL segments, separating words with underscores ('_') or hyphens ('-'). Some servers ignore case so it's best to be clear.
+* Keep URLs as short as possible, with as few segments as makes sense.
+
+## Use HTTP Response Codes to Indicate Status
+Response status codes are part of the HTTP specification. There are quite a number of them to address the most common situations. In the spirit of having our RESTful services embrace the HTTP specification, our Web APIs should return relevant HTTP status codes. For example, when a resource is successfully created (e.g. from a POST request), the API should return HTTP status code 201. A list of valid HTTP status codes is available here which lists detailed descriptions of each.
+
+Suggested usages for the "Top 10" HTTP Response Status Codes are as follows:
+
+| Status Code | Description |
+| ----------- | ----------- |
+| 200 OK      | General success status code. This is the most common code. Used to indicate success. |
+| 201 CREATED | Successful creation occurred (via either POST or PUT). Set the Location header to contain a link to the newly-created resource (on POST). Response body content may or may not be present. |
+| 204 NO CONTENT | Indicates success but nothing is in the response body, often used for DELETE and PUT operations. |
+| 400 BAD REQUEST | General error for when fulfilling the request would cause an invalid state. Domain validation errors, missing data, etc. are some examples. |
+| 401 UNAUTHORIZED | Error code response for missing or invalid authentication token. |
+| 403 FORBIDDEN | Error code for when the user is not authorized to perform the operation or the resource is unavailable for some reason (e.g. time constraints, etc.). |
+| 404 NOT FOUND | Used when the requested resource is not found, whether it doesn't exist or if there was a 401 or 403 that, for security reasons, the service wants to mask. |
+| 405 METHOD NOT ALLOWED | Used to indicate that the requested URL exists, but the requested HTTP method is not applicable. For example, POST /users/12345 where the API doesn't support creation of resources this way (with a provided ID). The Allow HTTP header must be set when returning a 405 to indicate the HTTP methods that are supported. In the previous case, the header would look like "Allow: GET, PUT, DELETE" |
+| 409 CONFLICT | Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries, such as trying to create two customers with the same information, and deleting root objects when cascade-delete is not supported are a couple of examples. |
+| 500 INTERNAL SERVER ERROR | __Never return this intentionally.__ The general catch-all error when the server-side throws an exception. Use this only for errors that the consumer cannot address from their end. |
+
+## Support JSON
+Favor JSON support unless you're in a highly-standardized and regulated industry that requires XML, schema validation and namespaces. If you must provide both JSON and XML let consumers switch between formats using the HTTP `Accept` header: `application/json` or `application/xml`.
+
+Be aware that as soon as we start talking about XML support, we start talking about schemas for validation, namespaces, etc. Unless required by your industry, avoid supporting all that complexity initially, if ever. JSON is designed to be simple, fairly terse and functional.
+
+## Create Fine-Grained Resources
+When starting out, it's best to create APIs that mimic the underlying application domain or database architecture of your system. Eventually, you'll want aggregate services that utilize multiple underlying resources to reduce chattiness. However, it's much easier to create larger resources later from individual resources than it is to create fine-grained or individual resources from larger aggregates. Make it easy on yourself and start with small, easily defined resources, providing CRUD functionality on those. You can create those use-case-oriented, chattiness-reducing resources later.
+
+## Consider Connectedness
+One of the principles of REST is connectedness—via hypermedia links (search HATEOAS). While services are still useful without them, APIs become more self-descriptive and discoverable when links are returned in the response. At the very least, a 'self' link reference informs clients how the data was or can be retrieved. Additionally, utilize the HTTP Location header to contain a link on resource creation via POST (or PUT). For collections returned in a response that support pagination, 'first', 'last', 'next' and 'prev' links at a minimum are very helpful.
+
+Regarding linking formats, there are many. The HTTP Web Linking Specification (RFC5988) explains a link as follows:
+
+> a link is a typed connection between two resources that are identified by Internationalised Resource Identifiers (IRIs) [RFC3987], and is comprised of:
+> * A context IRI,
+> * a link relation type
+> * a target IRI, and
+> * optionally, target attributes.
+>
+> A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}."
+
+At the very least, place links in the HTTP Link header as recommended in the specification, or embrace a JSON representation of this HTTP link style (such as Atom-style links, see: RFC4287) in your JSON representations. Later, you can layer in more complex linking styles such as HAL+JSON, Siren, Collection+JSON, and/or JSON-LD, etc. as your REST APIs become more mature.

content/basics/whatisrest.md

@@ -0,0 +1,140 @@
+---
+title: "What is REST?"
+date: 2022-06-06T16:35:40-06:00
+weight: 10
+---
+The term RESTful APIs or RESTful services is a hot topic. So what is REST? And how do we create a so-called RESTful API? Good question! Let's talk about this often misunderstood phrase...
+
+{{% notice info "A Loose Definition" %}}
+When someone says, "REST service," "REST API" or "RESTful API" they more-than-likely mean an HTTP or Web-based server that accepts requests over HTTP and responds in human-readable JSON.
+
+Yep, that really is it. But there are a lot of nuances--read on to discover more details!
+{{% /notice %}}
+
+Technically, REST is an acronym for "REpresentational State Transfer" which is simply an architectural style originally written about by Roy Fielding in his doctoral dissertation (see https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). You can read more details about the six contraints here, but first I want to give you a brief overview of what people mean when they say "REST."
+
+To be clear, the constraints in Roy Fielding's dissertation MUST be met in order for a service to be technically RESTful. And the REST constraints do not specify a communication protocol. However, at this point the term is used very loosely and in today's Internet world, RESTful almost always means an HTTP-based API. That means it operates in a request-response fashion over HTTP, usually using JSON as the data format in the request and response bodies. Though there are a lot of nuances, it's really just that simple!
+
+In other words, the caller (or client):
+* Makes an HTTP request to a URL...
+    * Using one of the standard HTTP methods (GET, PUT, POST, PATCH, DELETE, etc.)...
+    * With some content (usually JSON) in the body...
+* And waits for a response, which:
+    * Indicates status via an HTTP response code
+    * And usually has more JSON in the body.
+
+For example, say we wanted to search iTunes for RadioHead songs. We would call the iTunes Search API (See: https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/iTuneSearchAPI/index.html).
+
+We can use 'curl' on the command-line as follows. In this case all the query-string paremeters on the URL are simply telling the search API what term to search for (radiohead), how many results we want returned (3), and the type of media (music):
+```bash
+curl -i 'https://itunes.apple.com/search?term=radiohead&media=music&limit=3'
+```
+
+Which returns the following JSON response:
+
+```json
+{
+   "resultCount":3,
+   "results":[
+      {
+         "wrapperType":"track",
+         "kind":"song",
+         "artistId":657515,
+         "collectionId":1109714933,
+         "trackId":1109715066,
+         "artistName":"Radiohead",
+         "collectionName":"In Rainbows",
+         "trackName":"15 Step",
+         "collectionCensoredName":"In Rainbows",
+         "trackCensoredName":"15 Step",
+         "artistViewUrl":"https://music.apple.com/us/artist/radiohead/657515?uo=4",
+         "collectionViewUrl":"https://music.apple.com/us/album/15-step/1109714933?i=1109715066&uo=4",
+         "trackViewUrl":"https://music.apple.com/us/album/15-step/1109714933?i=1109715066&uo=4",
+         "previewUrl":"https://audio-ssl.itunes.apple.com/itunes-assets/AudioPreview125/v4/af/72/85/af728523-8048-4a8b-9e13-e8f4f64e9d69/mzaf_8205306206851675436.plus.aac.p.m4a",
+         "artworkUrl30":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/30x30bb.jpg",
+         "artworkUrl60":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/60x60bb.jpg",
+         "artworkUrl100":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/100x100bb.jpg",
+         "collectionPrice":9.99,
+         "trackPrice":1.29,
+         "releaseDate":"2007-10-10T07:00:00Z",
+         "collectionExplicitness":"notExplicit",
+         "trackExplicitness":"notExplicit",
+         "discCount":1,
+         "discNumber":1,
+         "trackCount":10,
+         "trackNumber":1,
+         "trackTimeMillis":237293,
+         "country":"USA",
+         "currency":"USD",
+         "primaryGenreName":"Alternative",
+         "isStreamable":true
+      },
+      {
+         "wrapperType":"track",
+         "kind":"song",
+         "artistId":657515,
+         "collectionId":1109714933,
+         "trackId":1109715161,
+         "artistName":"Radiohead",
+         "collectionName":"In Rainbows",
+         "trackName":"Bodysnatchers",
+         "collectionCensoredName":"In Rainbows",
+         "trackCensoredName":"Bodysnatchers",
+         "artistViewUrl":"https://music.apple.com/us/artist/radiohead/657515?uo=4",
+         "collectionViewUrl":"https://music.apple.com/us/album/bodysnatchers/1109714933?i=1109715161&uo=4",
+         "trackViewUrl":"https://music.apple.com/us/album/bodysnatchers/1109714933?i=1109715161&uo=4",
+         "previewUrl":"https://audio-ssl.itunes.apple.com/itunes-assets/AudioPreview115/v4/ba/e4/ac/bae4ac59-3bfa-e4b9-4f4c-03f667324fc0/mzaf_14837742185575446625.plus.aac.p.m4a",
+         "artworkUrl30":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/30x30bb.jpg",
+         "artworkUrl60":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/60x60bb.jpg",
+         "artworkUrl100":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/100x100bb.jpg",
+         "collectionPrice":9.99,
+         "trackPrice":1.29,
+         "releaseDate":"2007-10-10T07:00:00Z",
+         "collectionExplicitness":"notExplicit",
+         "trackExplicitness":"notExplicit",
+         "discCount":1,
+         "discNumber":1,
+         "trackCount":10,
+         "trackNumber":2,
+         "trackTimeMillis":242293,
+         "country":"USA",
+         "currency":"USD",
+         "primaryGenreName":"Alternative",
+         "isStreamable":true
+      },
+      {
+         "wrapperType":"track",
+         "kind":"song",
+         "artistId":657515,
+         "collectionId":1109714933,
+         "trackId":1109715168,
+         "artistName":"Radiohead",
+         "collectionName":"In Rainbows",
+         "trackName":"Weird Fishes / Arpeggi",
+         "collectionCensoredName":"In Rainbows",
+         "trackCensoredName":"Weird Fishes / Arpeggi",
+         "artistViewUrl":"https://music.apple.com/us/artist/radiohead/657515?uo=4",
+         "collectionViewUrl":"https://music.apple.com/us/album/weird-fishes-arpeggi/1109714933?i=1109715168&uo=4",
+         "trackViewUrl":"https://music.apple.com/us/album/weird-fishes-arpeggi/1109714933?i=1109715168&uo=4",
+         "previewUrl":"https://audio-ssl.itunes.apple.com/itunes-assets/AudioPreview115/v4/6c/e9/79/6ce9792e-c06a-b49b-6efe-60b96a690af8/mzaf_5478326228427438939.plus.aac.p.m4a",
+         "artworkUrl30":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/30x30bb.jpg",
+         "artworkUrl60":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/60x60bb.jpg",
+         "artworkUrl100":"https://is2-ssl.mzstatic.com/image/thumb/Music115/v4/9a/4f/8a/9a4f8a4b-0254-d5ab-74b5-ebe39bbbe85d/634904032463.png/100x100bb.jpg",
+         "collectionPrice":9.99,
+         "trackPrice":1.29,
+         "releaseDate":"2007-10-10T07:00:00Z",
+         "collectionExplicitness":"notExplicit",
+         "trackExplicitness":"notExplicit",
+         "discCount":1,
+         "discNumber":1,
+         "trackCount":10,
+         "trackNumber":4,
+         "trackTimeMillis":318187,
+         "country":"USA",
+         "currency":"USD",
+         "primaryGenreName":"Alternative",
+         "isStreamable":true
+      }
+   ]
+}
+```

content/httpstatuscodes/_index.md

@@ -0,0 +1,552 @@
++++
+title = "HTTP Status Codes"
+weight = 40
++++
+This page is created from HTTP status code information found at [ietf.org](https://www.ietf.org/assignments/http-status-codes/http-status-codes.xml) and [Wikipedia](https://en.wikipedia.org/wiki/HTTP_status_code). Click on the category heading or the status code link to read more.
+
+## 1xx Informational
+This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since `HTTP/1.0` did not define any `1xx` status codes, servers MUST NOT send a `1xx` response to an `HTTP/1.0` client except under experimental conditions.
+
+A client MUST be prepared to accept one or more `1xx` status responses prior to a regular response, even if the client does not expect a `100 (Continue)` status message. Unexpected `1xx` status responses MAY be ignored by a user agent.
+
+Proxies MUST forward `1xx` responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the `1xx` response. (For example, if a proxy adds a `Expect: 100-continue` field when it forwards a request, then it need not forward the corresponding `100 (Continue)` response(s).)
+
+{{% expand "100 Continue" %}}
+The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See [section 8.2.3] for detailed discussion of the use and handling of this status code.
+
+This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a `POST` request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send `Expect: 100-continue` as a header in its initial request and check if a `100 Continue` status code is received in response before continuing (or receive `417 Expectation Failed` and not continue).
+{{% /expand %}}
+
+{{% expand "101 Switching Protocols" %}}
+This means the requester has asked the server to switch protocols and the server is acknowledging that it will do so.
+
+The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the `101` response.
+
+The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of `HTTP` is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.
+{{% /expand %}}
+
+{{% expand "102 Processing (WebDAV)" %}}
+The `102 (Processing)` status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a `102 (Processing)` response. The server MUST send a final response after the request has been completed.
+
+Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a `102 (Processing)` status code to indicate to the client that the server is still processing the method.
+
+As a `WebDAV` request may contain many sub-requests involving file operations, it may take a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost.
+{{% /expand %}}
+
+## 2xx Success
+This class of status codes indicates the action requested by the client was received, understood, accepted, and processed successfully.
+
+{{% expand "★ 200 OK" %}}
+★ General status code. Most common code used to indicate success.
+
+The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
+- `GET` an entity corresponding to the requested resource is sent in the response.
+- `HEAD` the entity-header fields corresponding to the requested resource are sent in the response without any message-body.
+- `POST` an entity describing or containing the result of the action,
+- `TRACE` an entity containing the request message as received by the end server.
+{{% /expand %}}
+
+{{% expand "★ 201 Created" %}}
+★ Successful creation occurred (via either POST or PUT). Set the Location header to contain a link to the newly-created resource (on POST). Response body content may or may not be present.
+
+The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.
+
+A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.</p>
+{{% /expand %}}
+
+{{% expand "202 Accepted" %}}
+The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
+
+The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
+{{% /expand %}}
+
+{{% expand "203 Non-Authoritative Information" %}}
+The server successfully processed the request, but is returning information that may be from another source.
+
+The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).
+
+Not present in HTTP/1.0: available since HTTP/1.1
+{{% /expand %}}
+
+{{% expand "★ 204 No Content" %}}
+★ Status when nothing is in the response body (e.g. DELETE). The server successfully processed the request, but is not returning any content.
+
+The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
+
+If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
+
+The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
+{{% /expand %}}
+
+{{% expand "205 Reset Content" %}}
+The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requester reset the document view.
+
+The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.
+{{% /expand %}}
+
+{{% expand "206 Partial Content" %}}
+The server is delivering only part of the resource due to a range header sent by the client. The range header is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.
+
+The response MUST include the following header fields:
+- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.
+- Date
+- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
+- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
+
+If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
+
+A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.</p>
+A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.</p>
+{{% /expand %}}
+
+{{% expand "207 Multi-Status (WebDAV)" %}}
+The message response body contains an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.
+
+The 207 (Multi-Status) status code provides status for multiple independent operations (see section 11 for more information).
+{{% /expand %}}
+
+{{% expand "208 Already Reported (WebDAV)" %}}
+The members of a DAV binding have already been enumerated in a previous reply to this request, and are not being included again.
+
+The 208 (Already Reported) status code can be used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.  For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.
+{{% /expand %}}
+
+{{% expand "226 IM Used" %}}
+The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.  The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s).  If so, the headers of the resulting instance are the result of combining the headers from the status-226 response and the other instances, following the rules in section 13.5.3 of the HTTP/1.1 specification.
+
+The request MUST have included an A-IM header field listing at least one instance-manipulation.  The response MUST include an Etag header field giving the entity tag of the current instance.
+
+A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the requirements in section 10.6.
+
+A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance.
+{{% /expand %}}
+
+## 3xx Redirection
+This class of status code indicates that further action needs to be taken by the client in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is `GET` or `HEAD`. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.
+
+> __Note:__ previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation.
+
+
+{{% expand "300 Multiple Choices" %}}
+Indicates multiple options for the resource that the client may follow. It, for instance, could be used to present different format options for video, list files with different extensions, or word sense disambiguation.
+
+The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
+
+Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
+
+If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.
+{{% /expand %}}
+
+{{% expand "301 Moved Permanently" %}}
+This and all future requests should be directed to the given URI.
+
+The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
+
+The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
+
+If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
+
+> **Note:**</strong>** When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
+{{% /expand %}}
+
+{{% expand "302 Found" %}}
+The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
+
+The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
+
+If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
+
+> **Note:** RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request.  However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.</blockquote>
+
+This is an example of industry practice contradicting the standard.[2] The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours. However, some Web applications and frameworks use the 302 status code as if it were the 303.
+{{% /expand %}}
+
+{{% expand "303 See Other" %}}
+The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.
+
+This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
+
+The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
+
+> **Note:** Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
+
+Since HTTP/1.1
+{{% /expand %}}
+
+{{% expand "★ 304 Not Modified" %}}
+★ Used for conditional GET calls to reduce band-width usage. If used, must set the Date, Content-Location, ETag headers to what they would have been on a regular GET call. There must be no body on the response.
+
+Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
+
+If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
+
+The response MUST include the following header fields:
+- Date, unless its omission is required by section 14.18.1
+
+If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
+- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request</li>
+- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant</li>
+
+If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
+
+If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
+
+If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
+{{% /expand %}}
+
+{{% expand "305 Use Proxy" %}}
+The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.
+> **Note:** RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only.  Not observing these limitations has significant security consequences.
+
+Many HTTP clients (such as Mozilla and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons.
+{{% /expand %}}
+
+{{% expand "306 (Unused)" %}}
+The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.
+
+Originally meant "Subsequent requests should use the specified proxy."
+{{% /expand %}}
+
+{{% expand "307 Temporary Redirect" %}}
+In this case, the request should be repeated with another URI; however, future requests can still use the original URI. In contrast to 302, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.
+
+The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
+
+The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s), since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.
+
+If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
+{{% /expand %}}
+
+{{% expand "308 Permanent Redirect (experimental)" %}}
+The request, and all future requests should be repeated using another URI. 307 and 308 (as proposed) parallel the behaviours of 302 and 301, but do not require the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.
+{{% /expand %}}
+
+## 4xx Client Error
+The `4xx` class of status code is intended for cases in which the client seems to have erred. Except when responding to a `HEAD` request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. Clients SHOULD display any included entity to the user.
+
+If the client is sending data, a server implementation using `TCP` SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's `TCP` stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the `HTTP` application.
+
+{{% expand "★ 400 Bad Request" %}}
+★ General error when fulfilling the request would cause an invalid state. Syntax and domain validation errors, missing data, etc. are some examples.
+
+The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
+{{% /expand %}}
+
+{{% expand "★ 401 Unauthorized" %}}
+★ Error code response for missing or invalid authentication token.
+
+Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.
+
+The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication".
+{{% /expand %}}
+
+{{% expand "402 Payment Required" %}}
+This code is reserved for future use.
+
+The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code is not usually used. As an example of its use, however, Apple's MobileMe service generates a 402 error ("httpStatusCode:402" in the Mac OS X Console log) if the MobileMe account is delinquent.
+{{% /expand %}}
+
+{{% expand "★ 403 Forbidden" %}}
+★ Error code for user not authorized to perform the operation or the resource is unavailable for some reason (e.g. time constraints, etc.).
+
+The request was a legal request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference.
+
+The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
+{{% /expand %}}
+
+{{% expand "★ 404 Not Found" %}}
+★ Used when the requested resource is not found, whether it doesn't exist or if there was a 401 or 403 that, for security reasons, the service wants to mask.
+
+The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.
+
+The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
+{{% /expand %}}
+
+{{% expand "405 Method Not Allowed" %}}
+A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.
+
+The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.</p>
+{{% /expand %}}
+
+{{% expand "406 Not Acceptable" %}}
+The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.
+
+Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
+
+> **Note:** HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
+
+If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
+{{% /expand %}}
+
+{{% expand "407 Proxy Authentication Required" %}}
+The client must first authenticate itself with the proxy.
+
+This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication".
+{{% /expand %}}
+
+{{% expand "408 Request Timeout" %}}
+The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
+
+The server timed out waiting for the request. According to W3 HTTP specifications:
+> The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
+{{% /expand %}}
+
+{{% expand "★ 409 Conflict" %}}
+★ Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries and deleting root objects when cascade-delete is not supported are a couple of examples.
+
+Indicates that the request could not be processed because of conflict in the request, such as an edit conflict.
+
+The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
+
+Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
+{{% /expand %}}
+
+{{% expand "410 Gone" %}}
+Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a &quot;404 Not Found&quot; may be used instead.
+
+The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
+
+The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
+{{% /expand %}}
+
+{{% expand "411 Length Required" %}}
+The request did not specify the length of its content, which is required by the requested resource.
+
+The server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.</p>
+{{% /expand %}}
+
+{{% expand "412 Precondition Failed" %}}
+The server does not meet one of the preconditions that the requester put on the request.
+
+The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
+{{% /expand %}}
+
+{{% expand "413 Request Entity Too Large" %}}
+The request is larger than the server is willing or able to process.
+
+The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
+
+If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.
+{{% /expand %}}
+
+{{% expand "414 Request-URI Too Long" %}}
+The URI provided was too long for the server to process.
+
+The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.
+{{% /expand %}}
+
+{{% expand "415 Unsupported Media Type" %}}
+The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
+
+The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
+{{% /expand %}}
+
+{{% expand "416 Requested Range Not Satisfiable" %}}
+The client has asked for a portion of the file, but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file.
+
+A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)
+
+When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.
+{{% /expand %}}
+
+{{% expand "417 Expectation Failed" %}}
+The server cannot meet the requirements of the Expect request-header field.
+
+The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.
+{{% /expand %}}
+
+{{% expand "418 I'm a teapot (RFC 2324)" %}}
+This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. However, known implementations do exist. An Nginx HTTP server uses this code to simulate goto-like behaviour in its configuration.
+{{% /expand %}}
+
+{{% expand "420 Enhance Your Calm (Twitter)" %}}
+Returned by the Twitter Search and Trends API when the client is being rate limited. The text is a quote from 'Demolition Man' and the '420' code is likely a reference to this number's association with marijuana. Other services may wish to implement the 429 Too Many Requests response code instead.
+{{% /expand %}}
+
+{{% expand "422 Unprocessable Entity (WebDAV)" %}}
+The request was well-formed but was unable to be followed due to semantic errors.
+
+The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
+{{% /expand %}}
+
+{{% expand "423 Locked (WebDAV)" %}}
+The resource that is being accessed is locked.
+
+The 423 (Locked) status code means the source or destination resource of a method is locked.  This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
+{{% /expand %}}
+
+{{% expand "424 Failed Dependency (WebDAV)" %}}
+The request failed due to failure of a previous request (e.g. a PROPPATCH).
+
+The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed.  For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
+{{% /expand %}}
+
+{{% expand "425 Reserved for WebDAV" %}}
+Defined in drafts of &quot;WebDAV Advanced Collections Protocol&quot;, but not present in &quot;Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol&quot;.
+
+Slein, J., Whitehead, E.J., et al., &quot;WebDAV Advanced Collections Protocol&quot;,  Work In Progress.
+{{% /expand %}}
+
+{{% expand "426 Upgrade Required" %}}
+The client should switch to a different protocol such as TLS/1.0.
+
+Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.
+{{% /expand %}}
+
+{{% expand "428 Precondition Required" %}}
+The 428 status code indicates that the origin server requires the request to be conditional.
+
+Its typical use is to avoid the "lost update" problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.  By requiring requests to be conditional, the server can assure that clients are working with the correct copies.
+
+Responses using this status code SHOULD explain how to resubmit the request successfully.
+
+The 428 status code is optional; clients cannot rely upon its use to prevent &quot;lost update&quot; conflicts.
+{{% /expand %}}
+
+{{% expand "429 Too Many Requests" %}}
+The client has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.
+
+The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.
+
+When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.
+
+Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.
+{{% /expand %}}
+
+{{% expand "431 Request Header Fields Too Large" %}}
+The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large. The request MAY be resubmitted after reducing the size of the request header fields.
+
+It can be used both when the set of request header fields in total are too large, and when a single header field is at fault.  In the latter case, the response representation SHOULD specify which header field was too large.
+
+Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.
+{{% /expand %}}
+
+{{% expand "444 No Response (Nginx)" %}}
+An Nginx HTTP server extension. The server returns no information to the client and closes the connection (useful as a deterrent for malware).
+{{% /expand %}}
+
+{{% expand "449 Retry With (Microsoft)" %}}
+A Microsoft extension. The request should be retried after performing the appropriate action.
+{{% /expand %}}
+
+{{% expand "450 Blocked by Windows Parental Controls (Microsoft)" %}}
+A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.
+{{% /expand %}}
+
+{{% expand "451 Unavailable For Legal Reasons" %}}
+Intended to be used when resource access is denied for legal reasons, e.g. censorship or government-mandated blocked access. A reference to the 1953 dystopian novel Fahrenheit 451, where books are outlawed, and the autoignition temperature of paper, 451°F.
+{{% /expand %}}
+
+{{% expand "499 Client Closed Request (Nginx)" %}}
+An Nginx HTTP server extension. This code is introduced to log the case when the connection is closed by client while HTTP server is processing its request, making server unable to send the HTTP header back.
+{{% /expand %}}
+
+
+## 5xx Server Error
+The server failed to fulfill an apparently valid request.
+
+Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a `HEAD` request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. Clients SHOULD display any included entity to the user. These response codes are applicable to any request method.
+
+{{% expand "★ 500 Internal Server Error" %}}
+★ The general catch-all error when the server-side throws an exception. This indicates a service outage.
+
+The server encountered an unexpected condition which prevented it from fulfilling the request. A generic error message, given when no more specific message is suitable.
+{{% /expand %}}
+
+{{% expand "501 Not Implemented" %}}
+The server either does not recognise the request method, or it lacks the ability to fulfill the request.
+
+The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
+{{% /expand %}}
+
+{{% expand "502 Bad Gateway" %}}
+The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
+{{% /expand %}}
+
+{{% expand "503 Service Unavailable" %}}
+The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.
+
+The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
+
+> **Note:** The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.
+{{% /expand %}}
+
+{{% expand "504 Gateway Timeout" %}}
+The server was acting as a gateway or proxy and did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
+
+> **Note:** Some deployed proxies are known to return 400 or 500 when DNS lookups time out.
+{{% /expand %}}
+
+{{% expand "505 HTTP Version Not Supported" %}}
+The server does not support the HTTP protocol version used in the request.
+
+The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.
+{{% /expand %}}
+
+{{% expand "506 Variant Also Negotiates (Experimental)" %}}
+Transparent content negotiation for the request results in a circular reference.
+
+The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.
+{{% /expand %}}
+
+{{% expand "507 Insufficient Storage (WebDAV)" %}}
+The server is unable to store the representation needed to complete the request.
+
+The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.  This condition is considered to be temporary.  If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
+{{% /expand %}}
+
+{{% expand "508 Loop Detected (WebDAV)" %}}
+<a data-toggle="collapse" data-target="#loop_detected"></a>
+<div id="loop_detected" class="collapse">
+The server detected an infinite loop while processing the request (sent in lieu of 208).
+
+The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with &quot;Depth: infinity&quot;.  This status indicates that the entire operation failed.
+{{% /expand %}}
+
+{{% expand "509 Bandwidth Limit Exceeded (Apache)" %}}
+This status code, while used by many servers, is not specified in any RFCs.
+{{% /expand %}}
+
+{{% expand "510 Not Extended" %}}
+Further extensions to the request are required for the server to fulfill it.
+
+The policy for accessing the resource has not been met in the request.  The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.
+
+If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.
+{{% /expand %}}
+
+{{% expand "511 Network Authentication Required" %}}
+The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., &quot;captive portals&quot; used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).
+
+The response representation SHOULD contain a link to a resource that allows the user to submit credentials (e.g. with a HTML form).
+
+Note that the 511 response SHOULD NOT contain a challenge or the login interface itself, because browsers would show the login interface as being associated with the originally requested URL, which may cause confusion.
+
+The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.
+
+Responses with the 511 status code MUST NOT be stored by a cache.
+
+The 511 status code is designed to mitigate problems caused by &quot;captive portals&quot; to software (especially non-browser agents) that is expecting a response from the server that a request was made to, not the intervening network infrastructure.  It is not intended to encouraged deployment of captive portals, only to limit the damage caused by them.
+
+A network operator wishing to require some authentication, acceptance of terms or other user interaction before granting access usually does so by identifing clients who have not done so (&quot;unknown clients&quot;) using their MAC addresses.
+
+Unknown clients then have all traffic blocked, except for that on TCP port 80, which is sent to a HTTP server (the &quot;login server&quot;) dedicated to &quot;logging in&quot; unknown clients, and of course traffic to the login server itself.
+
+In common use, a response carrying the 511 status code will not come from the origin server indicated in the request's URL.  This presents many security issues; e.g., an attacking intermediary may be inserting cookies into the original domain's name space, may be observing cookies or HTTP authentication credentials sent from the user agent, and so on.
+
+However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues.
+
+Also, note that captive portals using this status code on an SSL or TLS connection (commonly, port 443) will generate a certificate error on the client.
+{{% /expand %}}
+
+{{% expand "598 Network read timeout error" %}}
+This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.
+{{% /expand %}}
+
+{{% expand "599 Network connect timeout error" %}}
+This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.
+{{% /expand %}}
+
+---
+
+★ **"Top 10"** HTTP Status Code. More REST service-specific information is contained in the entry.

content/resources/_index.md

@@ -0,0 +1,26 @@
++++
+title = "Resources"
+weight = 50
++++
+## Translations
+* [Russian](http://www.restapitutorial.ru/)
+
+## REST API Cheat Sheets
+* [API Design Cheat Sheet](https://github.com/RestCheatSheet/api-cheat-sheet#api-design-cheat-sheet) - This GitHub repository outlines important tips to consider when designing APIs that developers love.
+* [Platform-Building Cheat Sheet](https://github.com/RestCheatSheet/platform-cheat-sheet#platform-building-cheat-sheet) - Everyone wants to build a platform. This GitHub repository is a public receptical of ground rules when building a platform.
+
+## REST API Best Practices
+Get the RESTful Design Best Practices guide (choose your format). This guide reduces the world of RESTful services design into easy-to-follow principles. It also provides several cookbook type recipes in critical areas to increase service usability, reduce confusion during implemenation, as well as improve consistency.
+
+* [PDF](https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.pdf) (~306KB)
+* [ePub](https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.epub) (~46KB). Works on iPad, iPhone, B&N Nook and most other readers.
+* [Mobi](https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.mobi) (~86KB). Works on Kindle, Kindle Reader Apps
+* [Source Document in Libre/Open Office format](https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.odt) (~48KB)
+
+## Building REST APIs in Java
+[RestExpress](https://github.com/RestExpress/RestExpress) (GitHub). A lightweight microservices framework for Java, RestExpress composes best-of-breed tools to form a lightweight, minimalist Java framework for quickly creating RESTful APIs.
+
+## Web Resources
+* [REST API Tutorial YouTube Channel](https://www.youtube.com/user/restapitutorial) - The companion channel where all of the videos for this site live.
+* [Sascha Preibisch YouTube Channel](https://www.youtube.com/channel/UCBSlXL7WCE-MR8uuwurqVKA) - A great resource on Security; Particularly Oauth2 and OpenID Connect (OIDC).
+* [Todd Fredrich's Blog](http://www.toddfredrich.com/)

httpmethods.html

@@ -1,13 +0,0 @@
-<html>
-<head>
-  <title>Moved to new URL: http://www.restapitutorial.com/lessons/httpmethods.html</title>
-  <meta http-equiv=refresh content="0; url=http://www.restapitutorial.com/lessons/httpmethods.html" />
-  <meta name="robots" content="noindex,follow" />
-</head>
-<body>
-  <h1>This page has been moved to http://www.restapitutorial.com/lessons/httpmethods.html</h1>
-  <p>If your browser doesn't redirect you to the new location please
-    <a href="http://www.restapitutorial.com/lessons/httpmethods.html"><strong>click here</strong></a>,
-    sorry for the hassles!</p>
-</body>
-</html>

httpstatuscodes.html

@@ -7,43 +7,76 @@
 		<meta name="description" content="HTTP status codes and how to use them in RESTful API or Web Services.">
 		<meta name="author" content="Todd Fredrich, Pearson eCollege">
 		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
+		<link href="https://maxcdn.bootstrapcdn.com/twitter-bootstrap/2.0.4/css/bootstrap-combined.min.css" rel="stylesheet">
 		<style type="text/css">
 			body {
 				padding-top: 60px;
 				padding-bottom: 40px;
 			}
+			a {
+				cursor: pointer;
+			}
 		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
 		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
 		<!--[if lt IE 9]>
 		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
 		<![endif]-->
 		<script type="text/javascript">
-		
+
 		  var _gaq = _gaq || [];
 		  _gaq.push(['_setAccount', 'UA-31328878-1']);
 		  _gaq.push(['_trackPageview']);
-		
+
 		  (function() {
 		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
 		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
 		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
 		  })();
-		
+
 		</script>
+		<!-- Facebook Pixel Code -->
+		<script>
+		  !function(f,b,e,v,n,t,s)
+		  {if(f.fbq)return;n=f.fbq=function(){n.callMethod?
+		  n.callMethod.apply(n,arguments):n.queue.push(arguments)};
+		  if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
+		  n.queue=[];t=b.createElement(e);t.async=!0;
+		  t.src=v;s=b.getElementsByTagName(e)[0];
+		  s.parentNode.insertBefore(t,s)}(window, document,'script',
+		  'https://connect.facebook.net/en_US/fbevents.js');
+		  fbq('init', '389059184866929');
+		  fbq('track', 'PageView');
+		</script>
+		<noscript><img height="1" width="1" style="display:none"
+		  src="https://www.facebook.com/tr?id=389059184866929&ev=PageView&noscript=1"
+		/></noscript>
+		<!-- End Facebook Pixel Code -->
 	</head>
 	<body>
 		<div class="container">
+            <div class="row">
+                <div class="span12 banner-container">
+<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
+<!-- Rest API Tutorial -->
+<ins class="adsbygoogle"
+     style="display:block"
+     data-ad-client="ca-pub-2093481943685202"
+     data-ad-slot="4845828438"
+     data-ad-format="auto"></ins>
+<script>
+(adsbygoogle = window.adsbygoogle || []).push({});
+</script>
+                </div>
+            </div>
 			<div class="row">
 				<div class="span12">
 					<h1>HTTP Status Codes</h1>
-					<p>This page is created from HTTP status code information found at <a href="http://www.ietf.org/assignments/http-status-codes/http-status-codes.xml" target="_blank">ietf.org</a> and <a href="http://en.wikipedia.org/wiki/HTTP_status_code" target="_blank">Wikipedia</a>. Click on the <strong>category heading</strong> or the <strong>status code</strong> link to read more.</p>
+					<p>This page is created from HTTP status code information found at <a href="https://www.ietf.org/assignments/http-status-codes/http-status-codes.xml" target="_blank">ietf.org</a> and <a href="https://en.wikipedia.org/wiki/HTTP_status_code" target="_blank">Wikipedia</a>. Click on the <strong>category heading</strong> or the <strong>status code</strong> link to read more.</p>
 				</div>
 			</div>
 			<div class="row">
 				<div class="span12">
-					<h2><a  data-toggle="collapse" data-target="#1xx" href="#">1xx Informational</a></h2>
+					<h2><a  data-toggle="collapse" data-target="#1xx">1xx Informational</a></h2>
 					<div id="1xx" class="collapse">
 						<p>This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.</p>
 						<p>A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.</p>
@@ -56,7 +89,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#continue" href="#">100 Continue</a>
+					<a data-toggle="collapse" data-target="#continue">100 Continue</a>
 					<div id="continue" class="collapse">
 						<p>The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.</p>
 						<h3>Wikipedia</h3>
@@ -84,7 +117,7 @@
 			</div>
 			<div class="row">
 				<div class="span12">
-					<h2><a  data-toggle="collapse" data-target="#2xx" href="#">2xx Success</a></h2>
+					<h2><a  data-toggle="collapse" data-target="#2xx">2xx Success</a></h2>
 					<div id="2xx" class="collapse">
 						<p>This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
 						<h3>Wikipedia</h3>
@@ -94,7 +127,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#ok" href="#">200 OK</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#ok">200 OK</a>
 					<div id="ok" class="collapse">
 						<p>The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
 							<ul>
@@ -110,7 +143,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#created" href="#">201 Created</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#created">201 Created</a>
 					<div id="created" class="collapse">
 						<p>The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.</p>
 						<p>A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.</p>
@@ -120,7 +153,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#accepted" href="#">202 Accepted</a>
+					<a data-toggle="collapse" data-target="#accepted">202 Accepted</a>
 					<div id="accepted" class="collapse">
 						<p>The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.</p>
 						<p>The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.</p>
@@ -131,7 +164,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#nainfo" href="#">203 Non-Authoritative Information</a>
+					<a data-toggle="collapse" data-target="#nainfo">203 Non-Authoritative Information</a>
 					<div id="nainfo" class="collapse">
 						<p>The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).</p>
 						<h3>Wikipedia</h3>
@@ -140,18 +173,18 @@
 					</div>
 				</div>
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#nocontent" href="#">204 No Content</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#nocontent">204 No Content</a>
 					<div id="nocontent" class="collapse">
 						<p>The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.</p>
 						<p>If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.</p>
 						<p>The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.</p>
 						<h3>Wikipedia</h3>
 						<p>The server successfully processed the request, but is not returning any content.</p>
-						<p><i class="icon-star"></i> Indicates success but nothing is in the response body, often used for DELETE and UPDATE operations.</p>
+						<p><i class="icon-star"></i> Status when wrapped responses (e.g. JSEND) are not used and nothing is in the body (e.g. DELETE).</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#resetcontent" href="#">205 Reset Content</a>
+					<a data-toggle="collapse" data-target="#resetcontent">205 Reset Content</a>
 					<div id="resetcontent" class="collapse">
 						<p>The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.</p>
 						<h3>Wikipedia</h3>
@@ -161,7 +194,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#partialcontent" href="#">206 Partial Content</a>
+					<a data-toggle="collapse" data-target="#partialcontent">206 Partial Content</a>
 					<div id="partialcontent" class="collapse">
 						<p>The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.</p>
 						<p>The response MUST include the following header fields:</p>
@@ -179,7 +212,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#multi_status" href="#">207 Multi-Status (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#multi_status">207 Multi-Status (WebDAV)</a>
 					<div id="multi_status" class="collapse">
 						<p>The 207 (Multi-Status) status code provides status for multiple independent operations (see section 11 for more information).</p>
 						<h3>Wikipedia</h3>
@@ -187,7 +220,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#already_reported" href="#">208 Already Reported (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#already_reported">208 Already Reported (WebDAV)</a>
 					<div id="already_reported" class="collapse">
 						<p>The 208 (Already Reported) status code can be used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.  For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.</p>
 						<h3>Wikipedia</h3>
@@ -197,7 +230,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#im_used" href="#">226 IM Used</a>
+					<a data-toggle="collapse" data-target="#im_used">226 IM Used</a>
 					<div id="im_used" class="collapse">
 						<p>The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.  The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s).  If so, the headers of the resulting instance are the result of combining the headers from the status-226 response and the other instances, following the rules in section 13.5.3 of the HTTP/1.1 specification.</p>
 						<p>The request MUST have included an A-IM header field listing at least one instance-manipulation.  The response MUST include an Etag header field giving the entity tag of the current instance.</p>
@@ -213,7 +246,7 @@
 			</div>
 			<div class="row">
 				<div class="span12">
-					<h2><a data-toggle="collapse" data-target="#3xx" href="#">3xx Redirection</a></h2>
+					<h2><a data-toggle="collapse" data-target="#3xx">3xx Redirection</a></h2>
 					<div id="3xx" class="collapse">
 						<p>This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.</p>
 						<blockquote><strong>Note:</strong> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation.</blockquote>
@@ -225,7 +258,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#multiplechoices" href="#">300 Multiple Choices</a>
+					<a data-toggle="collapse" data-target="#multiplechoices">300 Multiple Choices</a>
 					<div id="multiplechoices" class="collapse">
 						<p>The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.</p>
 						<p>Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.</p>
@@ -235,7 +268,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#movepermanently" href="#">301 Moved Permanently</a>
+					<a data-toggle="collapse" data-target="#movepermanently">301 Moved Permanently</a>
 					<div id="movepermanently" class="collapse">
 						<p>The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.</p>
 						<p>The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).</p>
@@ -246,7 +279,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#found" href="#">302 Found</a>
+					<a data-toggle="collapse" data-target="#found">302 Found</a>
 					<div id="found" class="collapse">
 						<p>The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.</p>
 						<p>The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).</p>
@@ -259,7 +292,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#see_other" href="#">303 See Other</a>
+					<a data-toggle="collapse" data-target="#see_other">303 See Other</a>
 					<div id="see_other" class="collapse">
 						<p>The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.</p>
 						<p>The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).</p>
@@ -270,7 +303,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#not_modified" href="#">304 Not Modified</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#not_modified">304 Not Modified</a>
 					<div id="not_modified" class="collapse">
 						<p>If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.</p>
 						<p>The response MUST include the following header fields:</p>
@@ -287,10 +320,11 @@
 						<p>If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.</p>
 						<h3>Wikipedia</h3>
 						<p>Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.</p>
+						<p><i class="icon-star"></i> Used for conditional GET calls to reduce band-width usage. If used, must set the Date, Content-Location, ETag headers to what they would have been on a regular GET call.  There must be no body on the response.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#use_proxy" href="#">305 Use Proxy</a>
+					<a data-toggle="collapse" data-target="#use_proxy">305 Use Proxy</a>
 					<div id="use_proxy" class="collapse">
 						<p>The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.</p>
 						<blockquote>Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only.  Not observing these limitations has significant security consequences.</blockquote>
@@ -301,7 +335,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#306unused" href="#">306 (Unused)</a>
+					<a data-toggle="collapse" data-target="#306unused">306 (Unused)</a>
 					<div id="306unused" class="collapse">
 						<p>The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p>
 						<h3>Wikipedia</h3>
@@ -309,7 +343,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#temp_redirect" href="#">307 Temporary Redirect</a>
+					<a data-toggle="collapse" data-target="#temp_redirect">307 Temporary Redirect</a>
 					<div id="temp_redirect" class="collapse">
 						<p>The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.</p>
 						<p>The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.</p>
@@ -319,7 +353,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#perm_redirect" href="#">308 Permanent Redirect (experiemental)</a>
+					<a data-toggle="collapse" data-target="#perm_redirect">308 Permanent Redirect (experimental)</a>
 					<div id="perm_redirect" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>The request, and all future requests should be repeated using another URI. 307 and 308 (as proposed) parallel the behaviours of 302 and 301, but do not require the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.</p>
@@ -339,7 +373,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#bad_request" href="#">400 Bad Request</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#bad_request">400 Bad Request</a>
 					<div id="bad_request" class="collapse">
 						<p>The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.</p>
 						<h3>Wikipedia</h3>
@@ -348,7 +382,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#unauthorized" href="#">401 Unauthorized</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#unauthorized">401 Unauthorized</a>
 					<div id="unauthorized" class="collapse">
 						<p>The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication".</p>
 						<h3>Wikipedia</h3>
@@ -357,7 +391,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#pmt_required" href="#">402 Payment Required</a>
+					<a data-toggle="collapse" data-target="#pmt_required">402 Payment Required</a>
 					<div id="pmt_required" class="collapse">
 						<p>This code is reserved for future use.</p>
 						<h3>Wikipedia</h3>
@@ -367,7 +401,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#forbidden" href="#">403 Forbidden</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#forbidden">403 Forbidden</a>
 					<div id="forbidden" class="collapse">
 						<p>The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.</p>
 						<h3>Wikipedia</h3>
@@ -376,7 +410,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#not_found" href="#">404 Not Found</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#not_found">404 Not Found</a>
 					<div id="not_found" class="collapse">
 						<p>The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.</p>
 						<h3>Wikipedia</h3>
@@ -385,18 +419,17 @@
 					</div>
 				</div>
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#method_no_allowed" href="#">405 Method Not Allowed</a>
+					<a data-toggle="collapse" data-target="#method_no_allowed">405 Method Not Allowed</a>
 					<div id="method_no_allowed" class="collapse">
 						<p>The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.</p>
 						<h3>Wikipedia</h3>
 						<p>A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.</p>
-						<p><i class="icon-star"></i> Used to indicate that the requested URL exists, but the requested HTTP method is not applicable. For example, <em>POST /users/12345</em> where the API doesn't support creation of resources this way (with a provided ID). The Allow HTTP header must be set when returning a 405 to indicate the HTTP methods that are supported. In the previous case, the header would look like &quot;Allow: GET, PUT, DELETE&quot;</p>
 					</div>
 				</div>
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#not_acceptable" href="#">406 Not Acceptable</a>
+					<a data-toggle="collapse" data-target="#not_acceptable">406 Not Acceptable</a>
 					<div id="not_acceptable" class="collapse">
 						<p>The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.</p>
 						<p>Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.</p>
@@ -407,7 +440,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#proxy_auth_rqd" href="#">407 Proxy Authentication Required</a>
+					<a data-toggle="collapse" data-target="#proxy_auth_rqd">407 Proxy Authentication Required</a>
 					<div id="proxy_auth_rqd" class="collapse">
 						<p>This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication".</p>
 						<h3>Wikipedia</h3>
@@ -415,7 +448,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#request_timeout" href="#">408 Request Timeout</a>
+					<a data-toggle="collapse" data-target="#request_timeout">408 Request Timeout</a>
 					<div id="request_timeout" class="collapse">
 						<p>The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.</p>
 						<h3>Wikipedia</h3>
@@ -425,7 +458,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#conflict" href="#">409 Conflict</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#conflict">409 Conflict</a>
 					<div id="conflict" class="collapse">
 						<p>The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.</p>
 						<p>Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.</p>
@@ -435,7 +468,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#gone" href="#">410 Gone</a>
+					<a data-toggle="collapse" data-target="#gone">410 Gone</a>
 					<div id="gone" class="collapse">
 						<p>The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.</p>
 						<p>The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.</p>
@@ -444,7 +477,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#length_rqd" href="#">411 Length Required</a>
+					<a data-toggle="collapse" data-target="#length_rqd">411 Length Required</a>
 					<div id="length_rqd" class="collapse">
 						<p>The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.</p>
 						<h3>Wikipedia</h3>
@@ -454,7 +487,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#precondition_failed" href="#">412 Precondition Failed</a>
+					<a data-toggle="collapse" data-target="#precondition_failed">412 Precondition Failed</a>
 					<div id="precondition_failed" class="collapse">
 						<p>The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.</p>
 						<h3>Wikipedia</h3>
@@ -462,7 +495,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#request_entity_too_large" href="#">413 Request Entity Too Large</a>
+					<a data-toggle="collapse" data-target="#request_entity_too_large">413 Request Entity Too Large</a>
 					<div id="request_entity_too_large" class="collapse">
 						<p>The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.</p>
 						<p>If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.</p>
@@ -471,7 +504,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#request_uri_too_long" href="#">414 Request-URI Too Long</a>
+					<a data-toggle="collapse" data-target="#request_uri_too_long">414 Request-URI Too Long</a>
 					<div id="request_uri_too_long" class="collapse">
 						<p>The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.</p>
 						<h3>Wikipedia</h3>
@@ -481,7 +514,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#unsupported_media_type" href="#">415 Unsupported Media Type</a>
+					<a data-toggle="collapse" data-target="#unsupported_media_type">415 Unsupported Media Type</a>
 					<div id="unsupported_media_type" class="collapse">
 						<p>The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.</p>
 						<h3>Wikipedia</h3>
@@ -489,7 +522,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#requested_range_not_satisfiable" href="#">416 Requested Range Not Satisfiable</a>
+					<a data-toggle="collapse" data-target="#requested_range_not_satisfiable">416 Requested Range Not Satisfiable</a>
 					<div id="requested_range_not_satisfiable" class="collapse">
 						<p>A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)</p>
 						<p>When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.</p>
@@ -498,7 +531,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#expectation_failed" href="#">417 Expectation Failed</a>
+					<a data-toggle="collapse" data-target="#expectation_failed">417 Expectation Failed</a>
 					<div id="expectation_failed" class="collapse">
 						<p>The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.</p>
 						<h3>Wikipedia</h3>
@@ -508,21 +541,21 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#teapot" href="#">418 I'm a teapot (RFC 2324)</a>
+					<a data-toggle="collapse" data-target="#teapot">418 I'm a teapot (RFC 2324)</a>
 					<div id="teapot" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. However, known implementations do exist. An Nginx HTTP server uses this code to simulate goto-like behaviour in its configuration.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#enhance_your_calm" href="#">420 Enhance Your Calm (Twitter)</a>
+					<a data-toggle="collapse" data-target="#enhance_your_calm">420 Enhance Your Calm (Twitter)</a>
 					<div id="enhance_your_calm" class="collapse">
 						<h3>Wikipedia</h3>
-						<p>Returned by the Twitter Search and Trends API when the client is being rate limited. Likely a reference to this number's association with marijuana. Other services may wish to implement the 429 Too Many Requests response code instead.</p>
+						<p>Returned by the Twitter Search and Trends API when the client is being rate limited. The text is a quote from 'Demolition Man' and the '420' code is likely a reference to this number's association with marijuana. Other services may wish to implement the 429 Too Many Requests response code instead.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#unprocessable_entity" href="#">422 Unprocessable Entity (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#unprocessable_entity">422 Unprocessable Entity (WebDAV)</a>
 					<div id="unprocessable_entity" class="collapse">
 						<p>The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.</p>
 						<h3>Wikipedia</h3>
@@ -532,7 +565,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#locked" href="#">423 Locked (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#locked">423 Locked (WebDAV)</a>
 					<div id="locked" class="collapse">
 						<p>The 423 (Locked) status code means the source or destination resource of a method is locked.  This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.</p>
 						<h3>Wikipedia</h3>
@@ -540,7 +573,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#failed_dependency" href="#">424 Failed Dependency (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#failed_dependency">424 Failed Dependency (WebDAV)</a>
 					<div id="failed_dependency" class="collapse">
 						<p>The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed.  For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).</p>
 						<h3>Wikipedia</h3>
@@ -548,7 +581,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#adv_collections_expired" href="#">425 Reserved for WebDAV</a>
+					<a data-toggle="collapse" data-target="#adv_collections_expired">425 Reserved for WebDAV</a>
 					<div id="adv_collections_expired" class="collapse">
 						<p>Slein, J., Whitehead, E.J., et al., &quot;WebDAV Advanced Collections Protocol&quot;,  Work In Progress.</p>
 						<h3>Wikipedia</h3>
@@ -558,7 +591,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#upgrade_required" href="#">426 Upgrade Required</a>
+					<a data-toggle="collapse" data-target="#upgrade_required">426 Upgrade Required</a>
 					<div id="upgrade_required" class="collapse">
 						<p>Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.</p>
 						<h3>Wikipedia</h3>
@@ -566,48 +599,48 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#precondition_required" href="#">428 Precondition Required (draft)</a>
+					<a data-toggle="collapse" data-target="#precondition_required">428 Precondition Required</a>
 					<div id="precondition_required" class="collapse">
 						<p>The 428 status code indicates that the origin server requires the request to be conditional.</p>
 						<p>Its typical use is to avoid the "lost update" problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.  By requiring requests to be conditional, the server can assure that clients are working with the correct copies.</p>
 						<p>Responses using this status code SHOULD explain how to resubmit the request successfully.</p>
 						<p>The 428 status code is optional; clients cannot rely upon its use to prevent &quot;lost update&quot; conflicts.</p>
 						<h3>Wikipedia</h3>
-						<p>The origin server requires the request to be conditional. Intended to prevent &quot;the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.&quot; Specified in an Internet-Draft which is approved for publication as RFC.</p>
+						<p>The origin server requires the request to be conditional. Intended to prevent "the &quot;lost update&quot; problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#too_many_requests" href="#">429 Too Many Requests (draft)</a>
+					<a data-toggle="collapse" data-target="#too_many_requests">429 Too Many Requests</a>
 					<div id="too_many_requests" class="collapse">
 						<p>The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").</p>
 						<p>The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.</p>
 						<p>When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.</p>
 						<p>Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.</p>
 						<h3>Wikipedia</h3>
-						<p>The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes. Specified in an Internet-Draft which is approved for publication as RFC.</p>
+						<p>The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes.</p>
 					</div>
 				</div>
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#request_header_fields_too_large" href="#">431 Request Header Fields Too Large (draft)</a>
+					<a data-toggle="collapse" data-target="#request_header_fields_too_large">431 Request Header Fields Too Large</a>
 					<div id="request_header_fields_too_large" class="collapse">
 						<p>The 431 status code indicates that the server is unwilling to process the request because its header fields are too large.  The request MAY be resubmitted after reducing the size of the request header fields.</p>
 						<p>It can be used both when the set of request header fields in total are too large, and when a single header field is at fault.  In the latter case, the response representation SHOULD specify which header field was too large.</p>
 						<p>Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.</p>
 						<h3>Wikipedia</h3>
-						<p>The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large. Specified in an Internet-Draft which is approved for publication as RFC.</p>
+						<p>The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#no_response_nginx" href="#">444 No Response (Nginx)</a>
+					<a data-toggle="collapse" data-target="#no_response_nginx">444 No Response (Nginx)</a>
 					<div id="no_response_nginx" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>An Nginx HTTP server extension. The server returns no information to the client and closes the connection (useful as a deterrent for malware).</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#retry_with" href="#">449 Retry With (Microsoft)</a>
+					<a data-toggle="collapse" data-target="#retry_with">449 Retry With (Microsoft)</a>
 					<div id="retry_with" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>A Microsoft extension. The request should be retried after performing the appropriate action.</p>
@@ -616,14 +649,21 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#blocked_by_windows_parental" href="#">450 Blocked by Windows Parental Controls (Microsoft)</a>
+					<a data-toggle="collapse" data-target="#blocked_by_windows_parental">450 Blocked by Windows Parental Controls (Microsoft)</a>
 					<div id="blocked_by_windows_parental" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#client_closed_request" href="#">499 Client Closed Request (Nginx)</a>
+					<a data-toggle="collapse" data-target="#unavailable_for_legal_reasons">451 Unavailable For Legal Reasons</a>
+					<div id="unavailable_for_legal_reasons" class="collapse">
+						<h3>Wikipedia</h3>
+						<p>Intended to be used when resource access is denied for legal reasons, e.g. censorship or government-mandated blocked access. A reference to the 1953 dystopian novel Fahrenheit 451, where books are outlawed, and the autoignition temperature of paper, 451°F.</p>
+					</div>
+				</div>
+				<div class="span4">
+					<a data-toggle="collapse" data-target="#client_closed_request">499 Client Closed Request (Nginx)</a>
 					<div id="client_closed_request" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>An Nginx HTTP server extension. This code is introduced to log the case when the connection is closed by client while HTTP server is processing its request, making server unable to send the HTTP header back.</p>
@@ -646,16 +686,16 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#internal_server_error" href="#">500 Internal Server Error</a>
+					<i class="icon-star"></i> <a data-toggle="collapse" data-target="#internal_server_error">500 Internal Server Error</a>
 					<div id="internal_server_error" class="collapse">
 						<p>The server encountered an unexpected condition which prevented it from fulfilling the request.</p>
 						<h3>Wikipedia</h3>
 						<p>A generic error message, given when no more specific message is suitable.</p>
-						<p><i class="icon-star"></i> The general catch-all error when the server-side throws an exception. Use this only for errors that the consumer cannot address from their end&mdash;never return this intentionally.</p>
+						<p><i class="icon-star"></i> The general catch-all error when the server-side throws an exception.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#not_implemented" href="#">501 Not Implemented</a>
+					<a data-toggle="collapse" data-target="#not_implemented">501 Not Implemented</a>
 					<div id="not_implemented" class="collapse">
 						<p>The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.</p>
 						<h3>Wikipedia</h3>
@@ -663,7 +703,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#bad_gateway" href="#">502 Bad Gateway</a>
+					<a data-toggle="collapse" data-target="#bad_gateway">502 Bad Gateway</a>
 					<div id="bad_gateway" class="collapse">
 						<p>The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.</p>
 						<h3>Wikipedia</h3>
@@ -673,7 +713,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#service_unavailable" href="#">503 Service Unavailable</a>
+					<a data-toggle="collapse" data-target="#service_unavailable">503 Service Unavailable</a>
 					<div id="service_unavailable" class="collapse">
 						<p>The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.</p>
 						<blockquote>Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.</blockquote>
@@ -682,7 +722,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#gateway_timeout" href="#">504 Gateway Timeout</a>
+					<a data-toggle="collapse" data-target="#gateway_timeout">504 Gateway Timeout</a>
 					<div id="gateway_timeout" class="collapse">
 						<p>The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.</p>
 						<blockquote>Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.</blockquote>
@@ -691,7 +731,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#version_not_supported" href="#">505 HTTP Version Not Supported</a>
+					<a data-toggle="collapse" data-target="#version_not_supported">505 HTTP Version Not Supported</a>
 					<div id="version_not_supported" class="collapse">
 						<p>The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.</p>
 						<h3>Wikipedia</h3>
@@ -701,7 +741,7 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#variant_also_negotiates" href="#">506 Variant Also Negotiates (Experimental)</a>
+					<a data-toggle="collapse" data-target="#variant_also_negotiates">506 Variant Also Negotiates (Experimental)</a>
 					<div id="variant_also_negotiates" class="collapse">
 						<p>The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.</p>
 						<h3>Wikipedia</h3>
@@ -709,7 +749,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#insufficient_storage" href="#">507 Insufficient Storage (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#insufficient_storage">507 Insufficient Storage (WebDAV)</a>
 					<div id="insufficient_storage" class="collapse">
 						<p>The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.  This condition is considered to be temporary.  If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.</p>
 						<h3>Wikipedia</h3>
@@ -717,7 +757,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#loop_detected" href="#">508 Loop Detected (WebDAV)</a>
+					<a data-toggle="collapse" data-target="#loop_detected">508 Loop Detected (WebDAV)</a>
 					<div id="loop_detected" class="collapse">
 						<p>The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with &quot;Depth: infinity&quot;.  This status indicates that the entire operation failed.</p>
 						<h3>Wikipedia</h3>
@@ -727,14 +767,14 @@
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#bandwidth_limit_exceeded" href="#">509 Bandwidth Limit Exceeded (Apache)</a>
+					<a data-toggle="collapse" data-target="#bandwidth_limit_exceeded">509 Bandwidth Limit Exceeded (Apache)</a>
 					<div id="bandwidth_limit_exceeded" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>This status code, while used by many servers, is not specified in any RFCs.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#not_extended" href="#">510 Not Extended</a>
+					<a data-toggle="collapse" data-target="#not_extended">510 Not Extended</a>
 					<div id="not_extended" class="collapse">
 						<p>The policy for accessing the resource has not been met in the request.  The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.</p>
 						<p>If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.</p>
@@ -743,7 +783,7 @@
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#net_authn_required" href="#">511 Network Authentication Required (draft)</a>
+					<a data-toggle="collapse" data-target="#net_authn_required">511 Network Authentication Required</a>
 					<div id="net_authn_required" class="collapse">
 						<p>The 511 status code indicates that the client needs to authenticate to gain network access.</p>
 						<p>The response representation SHOULD contain a link to a resource that allows the user to submit credentials (e.g. with a HTML form).</p>
@@ -757,20 +797,20 @@
 						<p>However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues.</p>
 						<p>Also, note that captive portals using this status code on an SSL or TLS connection (commonly, port 443) will generate a certificate error on the client.</p>
 						<h3>Wikipedia</h3>
-						<p>The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g. &quot;captive portals&quot; used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot). Specified in an Internet-Draft which is approved for publication as RFC.</p>
+						<p>The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., &quot;captive portals&quot; used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).</p>
 					</div>
 				</div>
 			</div>
 			<div class="row">
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#network_read_timeout" href="#">598 Network read timeout error</a>
+					<a data-toggle="collapse" data-target="#network_read_timeout">598 Network read timeout error</a>
 					<div id="network_read_timeout" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.</p>
 					</div>
 				</div>
 				<div class="span4">
-					<a data-toggle="collapse" data-target="#network_connect_timeout" href="#">599 Network connect timeout error</a>
+					<a data-toggle="collapse" data-target="#network_connect_timeout">599 Network connect timeout error</a>
 					<div id="network_connect_timeout" class="collapse">
 						<h3>Wikipedia</h3>
 						<p>This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.</p>
@@ -788,19 +828,17 @@
 			</div>
 			<hr>
 			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012. All rights reserved.
-				</p>
+				<p><a rel="license" href="https://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />This work by <a xmlns:cc="https://creativecommons.org/ns#" href="https://www.restapitutorial.com/" property="cc:attributionName" rel="cc:attributionURL">RestApiTutorial.com</a> is licensed under a <a rel="license" href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.</p>
 			</footer>
 		</div> <!-- /container -->
 		<div class="navbar navbar-fixed-top">
 			<div class="navbar-inner">
 				<div class="container">
 					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
+					<a class="brand" href="https://www.restapitutorial.com">REST API Tutorial</a>
 					<div class="nav-collapse">
 						<ul class="nav">
-							<li><a href="http://www.restapitutorial.com">Home</a></li>
+							<li><a href="https://www.restapitutorial.com">Home</a></li>
 							<li class="dropdown" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
 								<ul class="dropdown-menu">
 									<li><a href="lessons/whatisrest.html">What Is REST?</a></li>
@@ -821,7 +859,7 @@
 		================================================== -->
 		<!-- Placed at the end of the document so the pages load faster -->
 		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
+		<script src="https://maxcdn.bootstrapcdn.com/twitter-bootstrap/2.0.4/js/bootstrap.min.js"></script>
+		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://camo.githubusercontent.com/365986a132ccd6a44c23a9169022c0b5c890c387/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub" data-canonical-src="https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png"></a>
 	</body>
 </html>

index.html

@@ -1,113 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>REST API Tutorial</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="The REST API Tutorial. Learn REST API best practices.">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<!-- Main hero unit for a primary marketing message or call to action -->
-			<div class="hero-unit">
-				<h1>Learn REST: A RESTful Tutorial</h1>
-				<p>Building restful web services, like other programming skills is <strong>part art, part science</strong>. As the Internet industry progresses, creating a REST API becomes more concrete, with emerging best practices. As RESTful Web services don't follow a prescribed standard except for HTTP, it's important to build your RESTful API in accordance with industry best practices to ease development and simplify client adoption.</p>
-				<p>Presently, there aren't a lot of REST API guides to help the lonely developer. <a href="http://www.restapitutorial.com">RestApiTutorial.com</a> is dedicated to tracking REST API best practices and making resources available to enable quick reference and self education for the development crafts-person.  We'll discuss both the art and science of creating REST Web services.</p>
-				<p>Jump in with <a href="lessons/whatisrest.html">What Is REST?</a>, an overview concepts and constraints of the RESTful architecture.</p>
-				<p><a class="btn btn-primary btn-large" href="lessons/whatisrest.html">Get Started &raquo;</a></p>
-			</div>
-<!--			<div class="row">
-				<div class="span3">
-					<a href="rest-api-overview.html"><img src="./img/restful-api-overview.jpg" alt="RESTful API Overview" height="200" width="200" /></a>
-					<h2>Get Started</h2>
-					<p>
-						What is REST? Discover what the six constraints are for creating a RESTful API.
-					</p>
-				</div>
-				<div class="span3">
-					<a href="rest-api-tips.html"><img src="./img/helpful-tips.jpg" alt="Helpful Tips" height="200" width="200" /></a>
-					<h2>Get Started</h2>
-					<p>
-						Get started quickly, creating your RESTful API quickly with these high-level, over-arching quick tips.
-					</p>
-				</div>
-				<div class="span3">
-					<a href="rest-api-topics.html"><img src="./img/advanced-topics.jpg" alt="Advanced Topics" width="200" height="200" /></a>
-					<h2>Get Better</h2>
-					<p>
-						Ready to dive deeper in the creating RESTful services?  Discover the more esoteric concepts of REST APIs.
-					</p>
-				</div>
-				<div class="span3">
-					<a href="rest-api-converstations.html"><img src="./img/conversations.png" alt="Conversations" width="200" height="200" /></a>
-					<h2>Get Building</h2>
-					<p>Introducing RestExpress, a Java framework to get building RESTful services quickly.</p>
-				</div>
-</div> -->
-			<hr>
-			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012. All rights reserved.
-				</p>
-				<p></p>
-			</footer>
-		</div>		<!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li class="active"><a href="http://www.restapitutorial.com">Home</a></li>
-							<li class="dropdown" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li><a href="lessons/whatisrest.html">What Is REST?</a></li>
-									<li><a href="lessons/restquicktips.html">REST Quick Tips</a></li>
-									<li><a href="lessons/httpmethods.html">HTTP Methods</a></li>
-									<li><a href="lessons/restfulresourcenaming.html">Resource Naming</a></li>
-									<li><a href="lessons/idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li><a href="resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

lessons/httpmethods.html

@@ -1,188 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>HTTP Methods for RESTful Services</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="HTTP methods tutorial on how to use them for RESTful API or Web Service.">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<div class="row">
-				<div class="span8">
-					<h1>Using HTTP Methods for RESTful Services</h1>
-				</div>
-				<div class="span4">
-					<ul class="pager">
-						<li>
-							<a href="restquicktips.html"><i class="icon-step-backward"></i> Quick-Tips</a>
-						</li>
-						<li>
-							<a href="restfulresourcenaming.html">Resource Naming <i class="icon-step-forward"></i></a>
-						</li>
-					</ul>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<p>The HTTP verbs comprise a major portion of our “uniform interface” constraint and provide us the action counterpart to the noun-based resource.  The primary or most-commonly-used HTTP verbs (or methods, as they are properly called) are POST, GET, PUT, and DELETE.  These correspond to create, read, update, and delete (or CRUD) operations, respectively.  There are a number of other verbs, too, but are utilized less frequently.  Of those less-frequent methods, OPTIONS and HEAD are used more often than others.</p>
-					<p>Below is a table summarizing recommended return values of the primary HTTP methods in combination with the resource URIs:</p>
-					<table class="table table-striped table-bordered">
-						<thead>
-							<tr>
-								<th>HTTP Verb</th>
-								<th>Entire Collection (e.g. /customers)</th>
-								<th>Specific Item (e.g. /customers/{id})</th>
-							</tr>
-						</thead>
-						<tbody>
-							<tr>
-								<td>GET</td>
-								<td>200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists.</td>
-								<td>200 (OK), single customer. 404 (Not Found), if ID not found or invalid.</td>
-							</tr>
-							<tr>
-								<td>PUT</td>
-								<td>404 (Not Found), unless you want to update/replace every resource in the entire collection.</td>
-								<td>200 (OK) or 204 (No Content).  404 (Not Found), if ID not found or invalid.</td>
-							</tr>
-							<tr>
-								<td>POST</td>
-								<td>201 (Created), 'Location' header with link to /customers/{id} containing new ID.</td>
-								<td>404 (Not Found).</td>
-							</tr>
-							<tr>
-								<td>DELETE</td>
-								<td>404 (Not Found), unless you want to delete the whole collection—not often desirable.</td>
-								<td>200 (OK).  404 (Not Found), if ID not found or invalid.</td>
-							</tr>
-						</tbody>
-					</table>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<p>Below is a more-detailed discussion of the main HTTP methods. Click on a tab for more information about the desired HTTP method.</p>
-					<ul class="nav nav-tabs">
-						<li class="active"><a href="#get" data-toggle="tab">GET</a></li>
-						<li><a href="#put" data-toggle="tab">PUT</a></li>
-						<li><a href="#post" data-toggle="tab">POST</a></li>
-						<li><a href="#delete" data-toggle="tab">DELETE</a></li>
-					</ul>
-					<div id="methodTabContent" class="tab-content">
-						<div class="tab-pane fade in active" id="get">
-							<p>The HTTP GET method is used to retrieve (or read) a representation of a resource.  In the “happy” (or non-error) path, GET returns a representation in XML or JSON and an HTTP response code of 200 (OK).  In an error case, it most often returns a 404 (NOT FOUND) or 400 (BAD REQUEST).</p>
-							<p>According to the design of the HTTP specification, GET (along with HEAD) requests are used only to read data and not change it.  Therefore, when used this way, they are considered safe.  That is, they can be called without risk of data modification or corruption—calling it once has the same effect as calling it 10 times, or none at all.  Additionally, GET (and HEAD) is idempotent, which means that making multiple identical requests ends up having the same result as a single request.</p>
-							<p>Do not expose unsafe operations via GET—it should never modify any resources on the server.</p>
-							<p><strong>Examples:</strong></p>
-							<ul>
-								<li><em>GET http://www.example.com/customers/12345</em></li>
-								<li><em>GET http://www.example.com/customers/12345/orders</em></li>
-								<li><em>GET http://www.example.com/buckets/sample</em></li>
-							</ul>
-						</div>
-						<div class="tab-pane fade" id="put">
-							<p>PUT is most-often utilized for update capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource.</p>
-							<p>However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server.  In other words, if the PUT is to a URI that contains the value of a non-existent resource ID.  Again, the request body contains a resource representation.  Many feel this is convoluted and confusing.  Consequently, this method of creation should be used sparingly, if at all.</p>
-							<p>Alternatively, use POST to create new resources and provide the client-defined ID in the body representation—presumably to a URI that doesn't include the ID of the resource (see POST below).</p>
-							<p>On successful update, return 200 (or 204 if not returning any content in the body) from a PUT.  If using PUT for create, return HTTP status 201 on successful creation.  A body in the response is optional—providing one consumes more bandwidth.   It is not necessary to return a link via a Location header in the creation case since the client already set the resource ID.</p>
-							<p>PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent.  In other words, if you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call.</p>
-							<p>If, for instance, calling PUT on a resource increments a counter within the resource, the call is no longer idempotent. Sometimes that happens and it may be enough to document that the call is not idempotent.  However, it's recommended to keep PUT requests idempotent.  It is strongly recommended to use POST for non-idempotent requests.</p>
-							<p><strong>Examples:</strong></p>
-							<ul>
-								<li><em>PUT http://www.example.com/customers/12345</em></li>
-								<li><em>PUT http://www.example.com/customers/12345/orders/98765</em></li>
-								<li><em>PUT http://www.example.com/buckets/secret_stuff</em></li>
-							</ul>
-						</div>
-						<div class="tab-pane fade" id="post">
-							<p>The POST verb is most-often utilized for creation of new resources.  In particular, it's used to create subordinate resources.  That is, subordinate to some other (e.g. parent) resource.  In other words, when creating a new resource, POST to the parent and the service takes care of associating the new resource with the parent, assigning an ID (new resource URI), etc.</p>
-							<p>On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.</p>
-							<p>POST is neither safe nor idempotent.  It is therefore recommended for non-idempotent resource requests.  Making two identical POST requests will most-likely result in two resources containing the same information.</p>
-							<p><strong>Examples:</strong></p>
-							<ul>
-								<li><em>POST http://www.example.com/customers</em></li>
-								<li><em>POST http://www.example.com/customers/12345/orders</em></li>
-							</ul>
-						</div>
-						<div class="tab-pane fade" id="delete">
-							<p>DELETE is pretty easy to understand.  It is used to delete a resource identified by a URI.
-							<p>On successful deletion, return HTTP status 200 (OK) along with a response body, perhaps the representation of the deleted item (often demands too much bandwidth), or a wrapped response (see Return Values below).  Either that or return HTTP status 204 (NO CONTENT) with no response body.  In other words, a 204 status with no body, or the JSEND-style response and HTTP status 200 are the recommended responses.</p>
-							<p>HTTP-spec-wise, DELETE operations are idempotent.  If you DELETE a resource, it's removed.  Repeatedly calling DELETE on that resource ends up the same: the resource is gone.  If calling DELETE say, decrements a counter (within the resource), the DELETE call is no longer idempotent.  As mentioned previously, usage statistics and measurements may be updated while still considering the service idempotent as long as no resource data is changed.  Using POST for non-idempotent resource requests is recommended.</p>
-							<p>There is a caveat about DELETE idempotence, however.  Calling DELETE on a resource a second time will often return a 404 (NOT FOUND) since it was already removed and therefore is no longer findable.  This makes DELETE operations no longer idempotent, but is an appropriate compromise if resources are removed from the database instead of being simply marked as deleted.</p>
-							<p><strong>Examples:</strong></p>
-							<ul>
-								<li><em>DELETE http://www.example.com/customers/12345</em></li>
-								<li><em>DELETE http://www.example.com/customers/12345/orders</em></li>
-								<li><em>DELETE http://www.example.com/bucket/sample</em></li>
-							</ul>
-						</div>
-					</div>
-				</div>
-			</div>
-			<hr>
-			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012. All rights reserved.
-				</p>
-			</footer>
-		</div> <!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li><a href="../index.html">Home</a></li>
-							<li class="dropdown active" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li><a href="whatisrest.html">What Is REST?</a></li>
-									<li><a href="restquicktips.html">REST Quick Tips</a></li>
-									<li class="active"><a href="httpmethods.html">HTTP Methods</a></li>
-									<li><a href="restfulresourcenaming.html">Resource Naming</a></li>
-									<li><a href="idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="../httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li><a href="../resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

lessons/idempotency.html

@@ -1,123 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>What is Idempotency?</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="Idempotency or Idempotence, definition in a non-academic way, specifically in REST APIs">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<div class="row">
-				<div class="span7">
-					<h1>What Is Idempotence?</h1>
-				</div>
-				<div class="span5">
-					<ul class="pager">
-						<li>
-							<a href="restfulresourcenaming.html"><i class="icon-step-backward"></i> Resource Naming</a>
-						</li>
-						<li>
-							<a href="../httpstatuscodes.html">HTTP Status Codes <i class="icon-step-forward"></i></a>
-						</li>
-					</ul>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<i class="icon-film"></i> <a href="#" data-toggle="collapse" data-target="#video1">Hide/Show Video</a>
-				</div>
-			</div>
-			<div id="video1" class="row collapse in">
-				<div class="span12">
-					<iframe width="853" height="480" src="http://www.youtube.com/embed/6dVNdFwqeKs" frameborder="0" allowfullscreen></iframe>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<h2>Idempotence</h2>
-				</div>
-				<div class="span12">
-					<p>Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition.</p>
-					<p>From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result—operating much like a “setter” method in a programming language. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (side effects), the response itself may not be the same (e.g. a resource's state may change between requests).</p>
-					<p>The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) on subsequent calls, unless the service is configured to "mark" resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next call will not find the resource to delete it and return a 404. However, the state on the server is the same after each DELETE call, but the response is different.</p>
-					<p>GET, HEAD, OPTIONS and TRACE methods are defined as safe, which makes them idempotent also. Read the section on safety below.</p>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<h2>Safetey</h2>
-				</div>
-				<div class="span12">
-					<p>Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition.</p>
-					<p>From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result—operating much like a “setter” method in a programming language. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (side effects), the response itself may not be the same (e.g. a resource's state may change between requests).</p>
-					<p>The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) on subsequent calls, unless the service is configured to "mark" resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next call will not find the resource to delete it and return a 404. However, the state on the server is the same after each DELETE call, but the response is different.</p>
-					<p>GET, HEAD, OPTIONS and TRACE methods are defined as safe, which makes them idempotent also. Read the section on safety below.</p>
-				</div>
-			</div>
-			<hr>
-			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012-2013. All rights reserved.
-				</p>
-			</footer>
-		</div> <!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li><a href="../index.html">Home</a></li>
-							<li class="dropdown active" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li><a href="whatisrest.html">What Is REST?</a></li>
-									<li><a href="restquicktips.html">REST Quick Tips</a></li>
-									<li><a href="httpmethods.html">HTTP Methods</a></li>
-									<li><a href="restfulresourcenaming.html">Resource Naming</a></li>
-									<li class="active"><a href="idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="../httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li><a href="../resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

lessons/restfulresourcenaming.html

@@ -1,185 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>RESTful Resource Naming</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="Naming Tutorial: RESTful services are resource-based. How do you create those noun-based resource names? Here's how...">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<div class="row">
-				<div class="span8">
-					<h1>Resource Naming</h1>
-				</div>
-				<div class="span4">
-					<ul class="pager">
-						<li>
-							<a href="httpmethods.html"><i class="icon-step-backward"></i> HTTP Methods</a>
-						</li>
-						<li>
-							<a href="idempotency.html">Idempotence <i class="icon-step-forward"></i></a>
-						</li>
-					</ul>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<p>In addition to utilizing the HTTP verbs appropriately, resource naming is arguably the most debated and most important concept to grasp when creating an understandable, easily leveraged Web service API. When resources are named well, an API is intuitive and easy to use. Done poorly, that same API can feel klutzy and be difficult to use and understand. Below are a few tips to get you going when creating the resource URIs for your new API.</p>
-					<p>Essentially, a RESTFul API ends up being simply a collection of URIs, HTTP calls to those URIs and some JSON and/or XML representations of resources, many of which will contain relational links. The RESTful principal of addressability is covered by the URIs. Each resource has its own address or URI—every interesting piece of information the server can provide is exposed as a resource. The constraint of uniform interface is partially addressed by the combination of URIs and HTTP verbs, and using them in line with the standards and conventions.</p>
-					<p>In deciding what resources are within your system, name them as nouns as opposed to verbs or actions. In other words, a RESTful URI should refer to a resource that is a thing instead of referring to an action. Nouns have properties as verbs do not, just another distinguishing factor.</p>
-					<p>Some example resources are:</p>
-					<ul>
-						<li>Users of the system.</li>
-						<li>Courses in which a student is enrolled.</li>
-						<li>A user's timeline of posts.</li>
-						<li>The users that follow another user.</li>
-						<li>An article about horseback riding.</li>
-					</ul>
-					<p>Each resource in a service suite will have at least one URI identifying it. And it's best when that URI makes sense and adequately describes the resource. URIs should follow a predictable, hierarchical structure to enhance understandability and, therefore, usability: predictable in the sense that they're consistent, hierarchical in the sense that data has structure—relationships. This is not a REST rule or constraint, but it enhances the API.</p>
-					<p>RESTful APIs are written for consumers. The name and structure of URIs should convey meaning to those consumers. It's often difficult to know what the data boundaries should be, but with understanding of your data, you most-likely are equipped to take a stab and what makes sense to return as a representation to your clients. Design for your clients, not for your data.</p>
-					<p>Let's say we're describing an order system with customers, orders, line items, products, etc. Consider the URIs involved in describing the resources in this service suite:</p>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<ul class="nav nav-tabs">
-						<li class="active"><a href="#examples" data-toggle="tab">Resource URI Examples</a></li>
-						<li><a href="#antipatterns" data-toggle="tab">Resource Naming Anti-Patterns</a></li>
-						<li><a href="#pluralization" data-toggle="tab">Pluralization</a></li>
-					</ul>
-					<div id="namingTabContent" class="tab-content">
-						<div class="tab-pane fade in active" id="examples">
-							<p>To insert (create) a new customer in the system, we might use:<br/>
-							<em>POST http://www.example.com/customers</em></p>
-							<p>To read a customer with Customer ID# 33245:<br/>
-							<em>GET http://www.example.com/customers/33245</em>
-							The same URI would be used for PUT and DELETE, to update and delete, respectively.</p>
-							<p>Here are proposed URIs for products:<br/>
-							<em>POST http://www.example.com/products</em>
-							for creating a new product.</p>
-							<p><em>GET|PUT|DELETE http://www.example.com/products/66432</em><br/>
-							for reading, updating, deleting product 66432, respectively.</p>
-							<p>Now, here is where it gets fun... What about creating a new order for a customer? One option might be: POST http://www.example.com/orders And that could work to create an order, but it's arguably outside the context of a customer.</p>
-							<p>Because we want to create an order for a customer (note the relationship), this URI perhaps is not as intuitive as it could be. It could be argued that the following URI would offer better clarity: <em>POST http://www.example.com/customers/33245/orders</em> Now we know we're creating an order for customer ID# 33245.</p>
-							<p>Now what would the following return?<br/>
-							<em>GET http://www.example.com/customers/33245/orders</em><br/>
-							Probably a list of orders that customer #33245 has created or owns. Note: we may choose to not support DELETE or PUT for that url since it's operating on a collection.</p>
-							<p>Now, to continue the hierarchical concept, what about the following URI?<br/>
-							<em>POST http://www.example.com/customers/33245/orders/8769/lineitems</em><br/>
-							That might add a line item to order #8769 (which is for customer #33245). Right! GET for that URI might return all the line items for that order. However, if line items don't make sense only in customer context or also make sense outside the context of a customer, we would offer a POST www.example.com/orders/8769/lineitems URI.</p>
-							<p>Along those lines, because there may be multiple URIs for a given resource, we might also offer a GET http://www.example.com/orders/8769 URI that supports retrieving an order by number without having to know the customer number.</p>
-							<p>To go one layer deeper in the hierarchy:<br/>
-							<em>GET http://www.example.com/customers/33245/orders/8769/lineitems/1</em><br/>
-							Might return only the first line item in that same order.</p>
-							<p>By now you can see how the hierarchy concept works. There aren't any hard and fast rules, only make sure the imposed structure makes sense to consumers of your services. As with everything in the craft of Software Development, naming is critical to success.</p>
-							<p>Look at some widely used APIs to get the hang of this and leverage the intuition of your teammates to refine your API resource URIs. Some example APIs are:</p>
-							<ul>
-								<li>Twitter: https://dev.twitter.com/docs/api</li>
-								<li>Facebook: http://developers.facebook.com/docs/reference/api/</li>
-								<li>LinkedIn: https://developer.linkedin.com/apis</li>
-							</ul>
-						</div>
-
-						<div class="tab-pane fade" id="antipatterns">
-							<p>While we've discussed some examples of appropriate resource names, sometimes it's informative to see some anti-patterns. Below are some examples of poor RESTful resource URIs seen in the &quot;wild.&quot; These are examples of what not to do!</p>
-							<p>First up, often services use a single URI to specify the service interface, using query-string parameters to specify the requested operation and/or HTTP verb. For example to update customer with ID 12345, the request for a JSON body might be:</p>
-							<p><em>GET http://api.example.com/services?op=update_customer&id=12345&format=json</em></p>
-							<p>By now, you're above doing this. Even though the 'services' URL node is a noun, this URL is not self- descriptive as the URI hierarchy is the same for all requests. Plus, it uses GET as the HTTP verb even though we're performing an update. This is counter-intuitive and is painful (even dangerous) to use as a client.</p>
-							<p>Here's another example following the same operation of updating a customer:</p>
-							<p><em>GET http://api.example.com/update_customer/12345</em></p>
-							<p>And its evil twin:</p>
-							<p><em>GET http://api.example.com/customers/12345/update</em></p>
-							<p>You'll see this one a lot as you visit other developer's service suites. Note that the developer is attempting to create RESTful resource names and has made some progress. But you're better than this —able to identify the verb phrase in the URL. Notice that we don't need to use the 'update' verb phrase in the URL because we can rely on the HTTP verb to inform that operation. Just to clarify, the following resource URL is redundant:</p>
-							<p><em>PUT http://api.example.com/customers/12345/update</em></p>
-							<p>With both PUT and 'update' in the request, we're offering to confuse our service consumers! Is 'update' the resource? So, we've spent some time beating the horse at this point. I'm certain you understand...</p>
-						</div>
-						<div class="tab-pane fade" id="pluralization">
-							<p>Let's talk about the debate between the pluralizers and the &quot;singularizers&quot;... Haven't heard of that debate? It does exist. Essentially, it boils down to this question...</p>
-							<p>Should URI nodes in your hierarchy be named using singular or plural nouns? For example, should your URI for retrieving a representation of a customer resource look like this:</p>
-							<p><em>GET http://www.example.com/customer/33245</em> or:
-							<em>GET http://www.example.com/customers/33245</em></p>
-							<p>There are good arguments on both sides, but the commonly-accepted practice is to always use plurals in node names to keep your API URIs consistent across all HTTP methods. The reasoning is based on the concept that customers are a collection within the service suite and the ID (e.g. 33245) refers to one of those customers in the collection.</p>
-							<p>Using this rule, an example multi-node URI using pluralization would look like (emphasis added):</p>
-							<p><em>GET http://www.example.com/<strong>customers</strong>/33245/<strong>orders</strong>/8769/<strong>lineitems</strong>/1</em></p>
-							<p>with 'customers', 'orders', and 'lineitems' URI nodes all being their plural forms.</p>
-							<p>This implies that you only really need two base URLs for each root resource. One for creation of the resource within a collection and the second for reading, updating and deleting the resource by its identifier. For example the creation case, using customers as the example, is handled by the following URL:</p>
-							<p><em>POST http://www.example.com/customers</em></p>
-							<p>And the read, update and delete cases are handled by the following:</p>
-							<p><em>GET|PUT|DELETE http://www.example.com/customers/{id}</em></p>
-							<p>As mentioned earlier, there may be multiple URIs for a given resource, but as a minimum full CRUD capabilities are aptly handled with two simple URIs.</p>
-							<p>You ask if there is a case where pluralization doesn't make sense. Well, yes, in fact there is. When there isn't a collection concept in play. In other words, it's acceptable to use a singularized resource name when there can only be one of the resource—it's a singleton resource. For example, if there was a single, overarching configuration resource, you might use a singularized noun to represent that:</p>
-							<p><em>GET|PUT|DELETE http://www.example.com/configuration</em></p>
-							<p>Note the lack of a configuration ID and usage of POST verb. And say that there was only one configuration per customer, then the URL might be:</p>
-							<p><em>GET|PUT|DELETE http://www.example.com/customers/12345/configuration</em></p>
-							<p>Again, no ID for the configuration and no POST verb usage. Although, I'm sure that in both of these cases POST usage might be argued to be valid. Well... OK.</p>
-						</div>
-					</div>
-				</div>
-			</div>
-			<hr>
-			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012. All rights reserved.
-				</p>
-			</footer>
-		</div> <!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li><a href="../index.html">Home</a></li>
-							<li class="dropdown active" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li><a href="whatisrest.html">What Is REST?</a></li>
-									<li><a href="restquicktips.html">REST Quick Tips</a></li>
-									<li><a href="httpmethods.html">HTTP Methods</a></li>
-									<li class="active"><a href="restfulresourcenaming.html">Resource Naming</a></li>
-									<li><a href="idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="../httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li><a href="../resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

lessons/restquicktips.html

@@ -1,176 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>RESTful Services Quick Tips</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="RESTful API or Web Service Quick Tips. Want to learn the high points of creating a REST API? Here's the Web Services in 60-seconds version.">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<div class="row">
-				<div class="span8">
-					<h1>REST API Quick Tips</h1>
-				</div>
-				<div class="span4">
-					<ul class="pager">
-						<li>
-							<a href="whatisrest.html"><i class="icon-step-backward"></i> What is REST?</a>
-						</li>
-						<li>
-							<a href="httpmethods.html">HTTP Methods <i class="icon-step-forward"></i></a>
-						</li>
-					</ul>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<p>Whether it's technically RESTful or not (according to the six constraints mentioned previously), here are a few recommended REST-like concepts. These six quick tips will result in better, more usable services.</p>
-					<h2>Use HTTP Verbs to Mean Something</h2>
-					<p>API consumers are capable of sending GET, POST, PUT, and DELETE verbs, and these verbs greatly enhance the clarity of what a given request does. Also, GET requests must not change any underlying resource data.  Measurements and tracking may still occur, which updates data, but not resource data identified by the URI.</p>
-                    <p>Generally, the four primary HTTP verb are used as follows:
-                    <dl>
-                        <dt>GET</dt>
-                            <dd>Read a specific resource (by an identifier) or a collection of resources.</dd>
-                        <dt>PUT</dt>
-                            <dd>Update a specific resource (by an identifier) or a collection of resources. Can also be used to create a specific resource if the resource identifier is know before-hand.</dd>
-                        <dt>DELETE</dt>
-                            <dd>Remove/delete a specific resource by an identifier.</dd>
-                        <dt>POST</dt>
-                            <dd>Create a new resource. Also a catch-all verb for operations that don't fit into the other categories.</dd>
-                    </dl>
-                    </p>
-					<h2>Provide Sensible Resource Names</h2>
-					<p>Producing a great API is 80% art and 20% science. Creating a URL hierarchy representing sensible resources is the art part. Having sensible resource names (which are just URL paths, such as /customers/12345/orders) improves the clarity of what a given request does.</p>
-					<p>Appropriate resource names provide context for a service request, increasing understandability of the API.  Resources are viewed hierarchically via their URI names, offering consumers a friendly, easily-understood hierarchy of resources to leverage in their applications.</p>
-                    <p>Here are some quick-hit rules for URL path (resource name) design:
-                        <ul>
-                            <li>Use identifiers in your URLs instead of in the query-string. Using URL query-string parameters is fantastic for filtering, but not for resource names.
-                            <ul><li><strong>Good:</strong> /users/12345</li><li><strong>Poor:</strong> /api?type=user&amp;id=23</li></ul></li>
-                            <li>Leverage the hierarchical nature of the URL to imply structure.</li>
-                            <li>Design for your clients, not for your data.</li>
-                            <li>Resource names should be nouns. Avoid verbs as resource names.  It makes things more clear.  Use the HTTP methods to specify the verb portion of the request.</li>
-                            <li>Use plurals in URL segments to keep your API URIs consistent across all HTTP methods, using the collection metaphor.
-                            <ul><li><strong>Recommended:</strong> /customers/33245/orders/8769/lineitems/1</li><li><strong>Not:</strong> /customer/33245/order/8769/lineitem/1</li></ul></li>
-                            <li>Avoid using collection verbage in URLs. For example 'customer_list' as a resource. Use pluralization to indicate the collection metaphor (e.g. customers vs. customer_list).</li>
-                            <li>Use lower-case in URL segments, separating words with underscores ('_') or hyphens ('-'). Some servers ignore case so it's best to be clear.</li>
-                            <li>Keep URLs as short as possible, with as few segments as makes sense.</li>
-                        </ul>
-                    </p>
-                    <h2>Use HTTP Response Codes to Indicate Status</h2>
-                    <p>Response status codes are part of the HTTP specification. There are quite a number of them to address the most common situations. In the spirit of having our RESTful services embrace the HTTP specification, our Web APIs should return relevant HTTP status codes. For example, when a resource is successfully created (e.g. from a POST request), the API should return HTTP status code 201.  A list of valid <a href="http://www.restapitutorial.com/httpstatuscodes.html">HTTP status codes</a> is available <a href="http://www.restapitutorial.com/httpstatuscodes.html">here</a> which lists detailed descriptions of each.</p>
-                    <p>Suggested usages for the &quot;Top 10&quot; HTTP Response Status Codes are as follows:
-                        <dl>
-                            <dt>200 OK</dt>
-                                <dd>General status code. Most common code used to indicate success.</dd>
-                            <dt>201 CREATED</dt>
-                                <dd>Successful creation occurred (via either POST or PUT). Set the Location header to contain a link to the newly-created resource (on POST). Response body content may or may not be present.</dd>
-                            <dt>204 NO CONTENT</dt>
-                                <dd>Indicates success but nothing is in the response body, often used for DELETE and UPDATE operations.</dd>
-                            <dt>400 BAD REQUEST</dt>
-                                <dd>General error when fulfilling the request would cause an invalid state. Domain validation errors, missing data, etc. are some examples.</dd>
-                            <dt>401 UNAUTHORIZED</dt>
-                                <dd>Error code response for missing or invalid authentication token.</dd>
-                            <dt>403 FORBIDDEN</dt>
-                                <dd>Error code for user not authorized to perform the operation or the resource is unavailable for some reason (e.g. time constraints, etc.).</dd>
-                            <dt>404 NOT FOUND</dt>
-                                <dd>Used when the requested resource is not found, whether it doesn't exist or if there was a 401 or 403 that, for security reasons, the service wants to mask.</dd>
-                            <dt>405 METHOD NOT ALLOWED</dt>
-                                <dd>Used to indicate that the requested URL exists, but the requested HTTP method is not applicable. For example, POST <em>/users/12345</em> where the API doesn't support creation of resources this way (with a provided ID). The Allow HTTP header must be set when returning a 405 to indicate the HTTP methods that are supported. In the previous case, the header would look like "Allow: GET, PUT, DELETE"</dd>
-                            <dt>409 CONFLICT</dt>
-                                <dd>Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries, such as trying to create two customers with the same information, and deleting root objects when cascade-delete is not supported are a couple of examples.</dd>
-                            <dt>500 INTERNAL SERVER ERROR</dt>
-                                <dd>Never return this intentionally. The general catch-all error when the server-side throws an exception. Use this only for errors that the consumer cannot address from their end.</dd>
-                        </dl>
-                    </p>
-					<h2>Offer Both JSON and XML</h2>
-					<p>Favor JSON support unless you're in a highly-standardize and regulated industry that requires XML, Schema validation and namespaces. And unless the costs of offering both JSON and XML are staggering, however, offer them both. Ideally, let consumers switch between using the HTTP Accept header, or by just changing an extension from .xml to .json on the URL.</p>
-					<p>Be warned though, as soon as we start talking about XML support, we start talking about schemas for validation, namespaces, etc. Unless required by your industry, avoid supporting all that complexity initially, if ever. JSON is designed to be simple, terse and functional. Create your XML to look like that if you can.</p>
-                    <p>In other words, make the XML that is returned more JSON-like: simple and easy to read, without the schema and namespace details present&mdash;just data and links.  If it ends up being more complex than this, the cost of XML will be staggering. In my experience nobody uses the XML responses anyway over the last several years.  It's just too expensive to consume.</p>
-                    <p>Note that <a href="http://json-schema.org/">JSON-Schema</a> offers schema-style validation capabilities, if you need that sort of thing.</p>
-					<h2>Create Fine-Grained Resources</h2>
-					<p>When starting out, it's much easier to create APIs that mimic the underlying application domain or database architecture of your system.  Eventually, you'll want aggregate services&mdash;services that utilize multiple underlying resources to reduce chattiness.  But it's much easier to create larger resources later from individual resources than it is to create fine-grained or individual resources from larger aggregates.  Make it easy on yourself and start with small, easily defined resources, providing CRUD functionality on those.  You can create those use-case-oriented, chattiness-reducing resources later.</p>
-					<h2>Consider Connectedness</h2>
-					<p>One of the principles of REST is connectedness—via hypermedia links (search HATEOAS).  While services are still useful without them, APIs become more self-descriptive and discoverable when links are returned in the response.  At the very least, a 'self' link reference informs clients how the data was or can be retrieved.  Additionally, utilize the HTTP Location header to contain a link on resource creation via POST (or PUT).  For collections returned in a response that support pagination, 'first', 'last', 'next' and 'prev' links at a minimum are very helpful.</p>
-                    <p>Regarding linking formats, there are many. The HTTP Web Linking Specification (<a href="http://tools.ietf.org/search/rfc5988">RFC5988</a>) explains a link as follows:
-                <blockquote>a link is a typed connection between two
-   resources that are identified by Internationalised Resource
-   Identifiers (IRIs) [<a href="http://tools.ietf.org/search/rfc3987">RFC3987</a>], and is comprised of:
-                    <ul>
-                        <li>A context IRI,</li>
-                        <li>a link relation type</li>
-                        <li>a target IRI, and</li>
-                        <li>optionally, target attributes.</li>
-                    </ul>
-   A link can be viewed as a statement of the form &quot;{context IRI} has a
-   {relation type} resource at {target IRI}, which has {target
-   attributes}.&quot;</blockquote></p>
-                    <p>At the very least, place links in the HTTP Link header as recommended in the specification.  Or embrace a JSON representation of this HTTP link style (such as Atom-style links, see: <a href="http://tools.ietf.org/search/rfc4287#section-4.2.7">RFC4287</a>) in your JSON representations. Later, you can layer in more complex linking styles such as <a href="http://stateless.co/hal_specification.html">HAL+JSON</a>, <a href="https://github.com/kevinswiber/siren">Siren</a>, <a href="http://amundsen.com/media-types/collection/">Collection+JSON</a>, and/or <a href="http://json-ld.org/">JSON-LD</a>, etc. as your REST APIs become more mature.</p>
-				</div>
-			</div>
-			<hr>
-			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012. All rights reserved.
-				</p>
-			</footer>
-		</div> <!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li><a href="../index.html">Home</a></li>
-							<li class="dropdown active" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li><a href="whatisrest.html">What Is REST?</a></li>
-									<li class="active"><a href="restquicktips.html">REST Quick Tips</a></li>
-									<li><a href="httpmethods.html">HTTP Methods</a></li>
-									<li><a href="restfulresourcenaming.html">Resource Naming</a></li>
-									<li><a href="idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="../httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li><a href="../resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

lessons/whatisrest.html

@@ -1,154 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>What is REST?</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="A tutorial on the six primary REST constraints as explained by Roy Fielding">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<div class="row">
-				<div class="span8">
-					<h1>What Is REST?</h1>
-				</div>
-				<div class="span4">
-					<ul class="pager">
-						<li>
-							<a href="../index.html"><i class="icon-step-backward"></i> Home</a>
-						</li>
-						<li>
-							<a href="restquicktips.html">Quick Tips <i class="icon-step-forward"></i></a>
-						</li>
-					</ul>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<i class="icon-film"></i> <a href="#" data-toggle="collapse" data-target="#video1">Hide/Show Video</a>
-				</div>
-			</div>
-			<div id="video1" class="row collapse in">
-				<div class="span12">
-					<iframe width="853" height="480" src="http://www.youtube.com/embed/llpr5924N7E" frameborder="0" allowfullscreen></iframe>
-				</div>
-			</div>
-			<div class="row">
-				<div class="span12">
-					<p>The REST architectural style describes six constraints.  These constraints, applied to the architecture, were originally communicated by Roy Fielding in his doctoral dissertation (see <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" target="_blank">http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm</a>) and defines the basis of RESTful-style.</p>
-					<p><strong>The six constraints are: (click the constraint to read more)</strong></p>
-					<ul id="constraint-accordian">
-						<li><a data-toggle="collapse" data-target="#uniform-interface" data-parent="#constraint-accordian" href="#">Uniform Interface</a>
-							<div class="collapse" id="uniform-interface">
-								<p>The uniform interface constraint defines the interface between clients and servers.  It simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of the uniform interface are:</p>
-								<h3>Resource-Based</h3>
-								<p>Individual resources are identified in requests using URIs as resource identifiers. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8, depending on the details of the request and the server implementation.</p>
-								<h3>Manipulation of Resources Through Representations</h3>
-								<p>When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so.</p>
-								<h3>Self-descriptive Messages</h3>
-								<p>Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cache-ability.</p>
-								<h3>Hypermedia as the Engine of Application State (HATEOAS)</h3>
-								<p>Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name).  Services deliver state to clients via body content, response codes, and response headers.  This is technically referred-to as hypermedia (or hyperlinks within hypertext).</p>
-								<p>Aside from the description above, HATEOS also means that, where necessary, links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects.  We'll talk about this in more detail later.</p>
-								<p>The uniform interface that any REST services must provide is fundamental to its design.</p>
-							</div>
-						</li>
-						<li><a data-toggle="collapse" data-target="#stateless" data-parent="#constraint-accordian" href="#">Stateless</a>
-							<div class="collapse" id="stateless">
-								<p>As REST is an acronym for REpresentational State Transfer, statelessness is key.  Essentially, what this means is that the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers.  The URI uniquely identifies the resource and the body contains the state (or state change) of that resource.  Then after the server does it's processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.</p>
-								<p>Most of us who have been in the industry for a while are accustomed to programming within a container which provides us with the concept of “session” which maintains state across multiple HTTP requests.  In REST, the client must include all information for the server to fulfill the request, resending state as necessary if that state must span multiple requests.  Statelessness enables greater scalability since the server does not have to maintain, update or communicate that session state.  Additionally, load balancers don't have to worry about session affinity for stateless systems.</p>
-								<p>So what's the difference between state and a resource?  State, or application state, is that which the server cares about to fulfill a request—data necessary for the current session or request.  A resource, or resource state, is the data that defines the resource representation—the data stored in the database, for instance.  Consider application state to be data that could vary by client, and per request.  Resource state, on the other hand, is constant across every client who requests it.</p>
-								<p>Ever had back-button issues with a web application where it went AWOL at a certain point because it expected you to do things in a certain order?  That's because it violated the statelessness principle. There are cases that don't honor the statelessness principle, such as three-legged OAuth, API call rate limiting, etc.  However, make every effort to ensure that application state doesn't span multiple requests of your service(s).</p>
-							</div>
-						</li>
-						<li><a data-toggle="collapse" data-target="#cacheable" data-parent="#constraint-accordian" href="#">Cacheable</a>
-							<div class="collapse" id="cacheable">
-								<p>As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.</p>
-							</div>
-						</li>
-						<li><a data-toggle="collapse" data-target="#client-server" data-parent="#constraint-accordian" href="#">Client-Server</a>
-							<div class="collapse" id="client-server">
-								<p>The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.</p>
-							</div>
-						</li>
-						<li><a data-toggle="collapse" data-target="#layered-system" data-parent="#constraint-accordian" href="#">Layered System</a>
-							<div class="collapse" id="layered-system">
-								<p>A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.</p>
-							</div>
-						</li>
-						<li><a data-toggle="collapse" data-target="#code-on-demand" data-parent="#constraint-accordian" href="#">Code on Demand (optional)</a>
-							<div class="collapse" id="code-on-demand">
-								<p>Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.</p>
-								<p>Complying with these constraints, and thus conforming to the REST architectural style, will enable any kind of distributed hypermedia system to have desirable emergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability and reliability.</p>
-								<p><strong>NOTE:</strong> The only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be referred to as RESTful.</p>
-							</div>
-						</li>
-					</ul>
-				</div>
-			</div>
-			<hr>
-			<footer>
-				<p>
-					&copy;Pearson eCollege, 2012. All rights reserved.
-				</p>
-			</footer>
-		</div> <!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li><a href="../index.html">Home</a></li>
-							<li class="dropdown active" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li class="active"><a href="whatisrest.html">What Is REST?</a></li>
-									<li><a href="restquicktips.html">REST Quick Tips</a></li>
-									<li><a href="httpmethods.html">HTTP Methods</a></li>
-									<li><a href="restfulresourcenaming.html">Resource Naming</a></li>
-									<li><a href="idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="../httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li><a href="../resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

resources.html

@@ -1,93 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-	<head>
-		<meta charset="utf-8">
-		<title>RESTful Web Services Resources</title>
-		<meta name="viewport" content="width=device-width, initial-scale=1.0">
-		<meta name="description" content="REST API eBook for Best Practices and other resources, such as open-source REST Service frameworks, etc.">
-		<meta name="author" content="Todd Fredrich, Pearson eCollege">
-		<!-- Le styles -->
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap.min.css" rel="stylesheet">
-		<style type="text/css">
-			body {
-				padding-top: 60px;
-				padding-bottom: 40px;
-			}
-		</style>
-		<link href="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/css/bootstrap-responsive.min.css" rel="stylesheet">
-		<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
-		<!--[if lt IE 9]>
-		<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
-		<![endif]-->
-		<script type="text/javascript">
-		  var _gaq = _gaq || [];
-		  _gaq.push(['_setAccount', 'UA-31328878-1']);
-		  _gaq.push(['_trackPageview']);
-		
-		  (function() {
-		    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
-		    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
-		    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
-		  })();
-		
-		</script>
-	</head>
-	<body>
-		<div class="container">
-			<div class="row">
-				<div class="span12">
-					<h1>REST API Resources</h1>
-					<h2>RESTful Best Practices</h2>
-					<p>Get the Pearson eCollege <em>RESTful Best Practices</em> guide (choose your format). This guide reduces the world of RESTful services into easy-to-follow principles. It also provides several cookbook type recipes in critical areas to increase service usability, reduce confusion during implemenation, as well as improve consistency.</p>
-					<ul>
-						<li><a href="https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.pdf">PDF</a> (~306KB)</li>
-						<li><a href="https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.epub">ePub</a> (~46KB). Works on iPad, iPhone, B&amp;N Nook and most other readers.</li>
-						<li><a href="https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful_Best_Practices_v1_2.mobi">Mobi</a> (~86KB). Works on Kindle, Kindle Reader Apps</li>
-						<li><a href="https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.odt">Source Document in Libre/Open Office format</a> (~48KB)</li>
-					</ul>
-					<h2>REST Services in Java</h2>
-					<p><a href="https://github.com/RestExpress/RestExpress">RestExpress</a> (GitHub). Create fast, scalable, stand-alone RESTful Web services in Java quickly.</p>
-					<h2>Web Resources</h2>
-					<ul>
-						<li><a href="http://www.youtube.com/user/restapitutorial">REST API Tutorial YouTube Channel</a></li>
-						<li><a href="http://www.toddfredrich.com">Todd Fredrich's API Blog</a></li>
-					</ul>
-				</div>
-			</div>
-			<hr>
-			<footer>
-				<p>&copy;Pearson eCollege, 2012. All rights reserved.</p>
-			</footer>
-		</div> <!-- /container -->
-		<div class="navbar navbar-fixed-top">
-			<div class="navbar-inner">
-				<div class="container">
-					<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse"> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </a>
-					<a class="brand" href="http://www.restapitutorial.com">REST API Tutorial</a>
-					<div class="nav-collapse">
-						<ul class="nav">
-							<li><a href="http://www.restapitutorial.com">Home</a></li>
-							<li class="dropdown" id="api-school"><a class="dropdown-toggle" data-toggle="dropdown" href="#">Tutorials<b class="caret"></b></a>
-								<ul class="dropdown-menu">
-									<li><a href="lessons/whatisrest.html">What Is REST?</a></li>
-									<li><a href="lessons/restquicktips.html">REST Quick Tips</a></li>
-									<li><a href="lessons/httpmethods.html">HTTP Methods</a></li>
-									<li><a href="lessons/restfulresourcenaming.html">Resource Naming</a></li>
-									<li><a href="lessons/idempotency.html">Idempotence</a></li>
-								</ul>
-							</li>
-							<li><a href="httpstatuscodes.html">HTTP Status Codes</a></li>
-							<li class="active"><a href="resources.html">Resources</a></li>
-						</ul>
-					</div><!--/.nav-collapse -->
-				</div>
-			</div>
-		</div>
-		<!-- Le javascript
-		================================================== -->
-		<!-- Placed at the end of the document so the pages load faster -->
-		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
-		<script src="https://d7im4lln3lvbg.cloudfront.net/bootstrap/2.0.1/js/bootstrap.min.js"></script>
-		<a href="https://github.com/tfredrich/RestApiTutorial.com"><img style="position: absolute; top: 0; right: 0; border: 0; z-index: 1050;" src="https://a248.e.akamai.net/camo.github.com/e6bef7a091f5f3138b8cd40bc3e114258dd68ddf/687474703a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f7265645f6161303030302e706e67" alt="Fork me on GitHub"></a>
-	</body>
-</html>

restquicktips.html

@@ -1,13 +0,0 @@
-<html>
-<head>
-  <title>Moved to new URL: http://www.restapitutorial.com/lessons/restquicktips.html</title>
-  <meta http-equiv=refresh content="0; url=http://www.restapitutorial.com/lessons/restquicktips.html" />
-  <meta name="robots" content="noindex,follow" />
-</head>
-<body>
-  <h1>This page has been moved to http://www.restapitutorial.com/lessons/restquicktips.html</h1>
-  <p>If your browser doesn't redirect you to the new location please
-    <a href="http://www.restapitutorial.com/lessons/restquicktips.html"><strong>click here</strong></a>,
-    sorry for the hassles!</p>
-</body>
-</html>

sitemap.xml

@@ -1,43 +1,47 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <urlset
-      xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
-      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-      xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9
-            http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd">
+      xmlns="https://www.sitemaps.org/schemas/sitemap/0.9"
+      xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
+      xsi:schemaLocation="https://www.sitemaps.org/schemas/sitemap/0.9
+            https://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd">
 <url>
-  <loc>http://www.restapitutorial.com/</loc>
-  <lastmod>2014-02-03T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/</loc>
+  <lastmod>2018-07-03T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/lessons/whatisrest.html</loc>
-  <lastmod>2013-09-04T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/lessons/whatisrest.html</loc>
+  <lastmod>2015-01-14T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/lessons/restquicktips.html</loc>
-  <lastmod>2014-02-03T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/lessons/restquicktips.html</loc>
+  <lastmod>2017-12-29T21:54:09+07:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/lessons/httpmethods.html</loc>
-  <lastmod>2013-09-04T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/lessons/httpmethods.html</loc>
+  <lastmod>2017-05-12T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/lessons/restfulresourcenaming.html</loc>
-  <lastmod>2013-09-04T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/lessons/restfulresourcenaming.html</loc>
+  <lastmod>2017-12-29T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/lessons/idempotency.html</loc>
-  <lastmod>2013-09-21T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/lessons/idempotency.html</loc>
+  <lastmod>2015-02-14T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/httpstatuscodes.html</loc>
-  <lastmod>2014-02-03T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/httpstatuscodes.html</loc>
+  <lastmod>2017-05-12T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/resources.html</loc>
-  <lastmod>2013-21-21T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/resources.html</loc>
+  <lastmod>2021-01-05T12:55:39+00:00</lastmod>
 </url>
 <url>
-  <loc>http://www.restapitutorial.com/index.html</loc>
-  <lastmod>2013-09-21T14:55:39+00:00</lastmod>
+  <loc>https://www.restapitutorial.com/index.html</loc>
+  <lastmod>2018-07-03T12:55:39+00:00</lastmod>
 </url>
-</urlset>
+<url>
+  <loc>https://www.restapitutorial.com/restapiwebinar.html</loc>
+  <lastmod>2018-06-10T12:55:39+00:00</lastmod>
+</url>
+</urlset>