REST API GET and POST Request contents added.

Author: anishmanandhar

docs/rest-api/get.md

@@ -4,4 +4,18 @@ title: Get Method
 sidebar_label: Get
 ---
 
-#### The following convention should be followed for Get
+Use **GET requests** to retrieve resource representation/information only – and not to modify it in any way. As GET requests do not change the state of the resource, these are said to be safe methods. Additionally, GET APIs should be **idempotent**, which means that making multiple identical requests must produce the same result every time until another API (POST/PUT/PATCH/DELETE) has changed the state of the resource on the server.
+
+> * **/employees**
+> * **/employees/{employee-id}/leaves**
+> * **/employees/{employee-id}/employee-reports**
+
+|  Response code            |  Result/Reason |
+|---------------------------|------------------------------|
+|200 OK                     | Sucessfully Fetched the Enity. <br/> Must include a response body. |
+|404 (Not found)            | If Entity not found for given ID or is invalid ID|
+|405 (Method Not allowed)   | If API supports methods other than GET request |
+|401 (Unauthorized)         | Invalid Credentials/ Invalid Authentication |
+|403 (Forbidden)            | Invalid Authorization/ Insufficient rights/ Incorrect Role |
+|410 (Gone)                 | Expired link/Server no longer serve this request.|
+|500 (Internal server error)| Server encountered an unexpected condition that prevented it from fulfilling the request. |

docs/rest-api/naming-convention.md

@@ -0,0 +1,18 @@
+---
+id: naming-convention
+title: Naming Convention
+sidebar_label: Naming Convention
+---
+
+In REST(**REpresentational State Transfer**), primary data **representation** is called **Resource**. Having a strong and consistent REST resource naming strategy – will definitely prove one of the best design decisions in the long term.
+
+* Use **noun** and **hyphenated-lower-case** for CRUD operations to an entity/resource/document. The **GET/POST/PUT/DELETE/PATCH** requests represents the corresponding CRUD operation for the following resources like employees, reports, leaves.
+  
+> * **/employees**
+> * **/employees/{employee-id}/leaves**
+> * **/employees/{employee-id}/employee-reports**
+
+* For cases of executable functions besides a basic CRUD operations, use **verb** and **hyphenated-lower-case**.
+
+> * **/customer/{customer-id}/check-validity**
+> * **/customer/{customer-id}/cart/checkout**

docs/rest-api/post.md

@@ -4,4 +4,20 @@ title: Post Method
 sidebar_label: Post
 ---
 
-#### The following convention should be followed for Post
+Use **POST requests** to create new subordinate resources, e.g., a file is subordinate to a directory containing it or a row is subordinate to a database table. Talking strictly in terms of REST, POST methods are used to create a new resource into the collection of resources.Note that POST is **neither safe nor idempotent**, and invoking two identical POST requests will result in two different resources containing the same information (except resource ids).
+
+> * **/employees**
+> * **/employees/{employee-id}/leaves**
+> * **/employees/{employee-id}/employee-reports**
+
+|  Response code            |  Result/Reason |
+|---------------------------|------------------------------|
+|201 OK                     | Sucessfully Created the Enity. <br/> Must include a response body. |
+|202 (Accepted)             | Actions that take a long while to process/ Batch/Queue Oriented Process |
+|204 (No Content)           | When the REST API declines to send back any status message or representation in the response message’s body. Must not contains the response body|
+|401 (Unauthorized)         | Invalid Credentials/ Invalid Authentication |
+|403 (Forbidden)            | Invalid Authorization/ Insufficient rights/ Incorrect Role |
+|400 (Bad Request)           | Bad request object | validation error |
+|405 (Method Not allowed)   | If API supports methods other than GET request |
+|410 (Gone)                 | Expired link/Server no longer serve this request.|
+|500 (Internal server error)| Server encountered an unexpected condition that prevented it from fulfilling the request.|

docs/rest-api/security.md

@@ -6,21 +6,14 @@ sidebar_label: Security
 
 ## Best Practices to Secure REST APIs
 
-### Always Use HTTPS
+* Always Use HTTPS.If you use HTTP 2, to improve performance – you can even send multiple requests over a single connection, that way you avoid the complete TCP and SSL handshake overhead on later requests.
 
-* By always using SSL, the authentication credentials can be simplified to a randomly generated access token that is delivered in the username field of HTTP Basic Auth. It’s relatively simple to use, and you get a lot of security features for free.
-  
-* If you use HTTP 2, to improve performance – you can even send multiple requests over a single connection, that way you avoid the complete TCP and SSL handshake overhead on later requests.
+* Never expose information on URLs. <https://api.app.com/users/{id}/fetch?apiKey=abcd123456789> //Bad practice
 
-### Never expose information on URLs
+* Conside using token based authentication like OAUTH2
 
-* Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them easily exploitable. e.g  
- https://api.app.com/users/{id}/fetch?apiKey=abcd123456789  //Bad practice
+* Consider Adding Timestamp in Request
 
-### Conside using token based authentication like OAUTH2
+* Log each request and response data
 
-### Consider Adding Timestamp in Request
-
-### Log each request and response data
-
-### Validate Incoming request
+* Validate and sanitize incoming requests against data types, injections

sidebars.js

@@ -10,6 +10,7 @@ module.exports =
         "type": "category",
         "label": "Methods",
         "items": [
+          "rest-api/naming-convention",
           "rest-api/get",
           "rest-api/post",
           "rest-api/put",