1. URI definition
   1. Uniform Resource Identifiers
   2. Format
      1. URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]
   3. Rules
      1. Forward slash separator (/)
         1. must be used to indicate a hierarchical relationship
         2. should not be included in URIs end
            1. Ex : http://api.canvas.restapi.org/shapes/
      2. use Hyphens (-)
      3. Do not use Underscores (_)
      4. Lowercase letters should be preferred
      5. File extensions should not be included
         1. Ex : http://api..../fall.json
2. URI Path Design
   1. Do not use CRUD commands or verbs
      1. /deleteUser?userId=123
      2. /create/
      3. do not use HTTP methods
      4. /getuserId/123
      5. /getNextSequence
      6. * NEVER USE CRUD COMMANDS OR VERBS * DONOT USE METHODS NAMES
   2. Documents
      1. SINGULAR NOUN
         1. /repos/{owner}/{repo}/tags
         2. {owner} is a document; should be SINGULAR NOUN
   3. Collection
      1. PLURAL NOUN
         1. /repos/{owner}/{repo}/tags
         2. "repos" is a collection; should be PLURAL NOUN
   4. Store
      1. PLURAL NOUN
         1. /repos/{owner}/{repo}/tags
         2. "tags" is a collection; should be PLURAL NOUN
   5. Variable path segments may be substituted with identity-based values
      1. /users/123
      2. /users/3444-566-DF44-GT11
   6. Summary do and do not
      1. DELETEL: /users/1234
         1. /deleteuser?userId=1234
      2. /users
         1. /user
      3. /students/csandun/courses
         1. /getStudentCourses?user=csandun
      4. /students/12
         1. /students/getbyid/12
      5. /students/next
         1. /students/get-next-id
         2. /getNextStudentId
3. URI Query Design
   1. Filter
      1. Collection
         1. GET: /Users
         2. GET: /users?role=admin
         3. a listing of all the users in the collection.
         4. a filtered list of all the users inthe collection with a “role” value of admin
   2. Pagination
      1. Collection
      2. Store
   3. filter collections or stores
   4. paginate collection or store results
      1. GET verb with Querys
         1. GET /users?pagesize=25&pageindex=2
         2. for simple filteration
      2. POST verb
         1. POST /users/search
         2. the complexity of a client’s pagination
4. HTTP methods
   1. GET
      1. retrieve a resource from the server
      2. safe or idempotent
   2. POST
      1. create a new resource on the server.
      2. not safe or not idempotent
   3. PUT
      1. update an existing resource on the server.
      2. not safe, but it is idempotent
   4. DELETE
      1. delete a resource from the server
      2. not safe or idempotent
   5. PATCH
      1. apply a set of changes exist resource
   6. HEAD
      1. only retrieves the HTTP headers for a resources
   7. OPTIONS
      1. describe the options available for a resource
      2. describes supported HTTP verbs
5. Response Codes
   1. 1xx
      1. Information
      2. Communicates transfer protocol-level information.
   2. 2xx
      1. Success
      2. Indicates that the client’s request was accepted successfully
   3. 3xx
      1. Redirection
      2. Indicates that the client must take some additional action in order to complete their request
   4. 4xx
      1. Client error
      2. This category of error status codes points the finger at clients
   5. 5xx
      1. Server error
      2. The server takes responsibility for these error status codes.
6. Versioning
   1. The practice of transparently managing changes to your API
   2. maintain backward compatibility
   3. Approches
      1. URI Versioning
         1. the version of the API is included in the URL path.
            1. http://api.example.com/v1/resource
            2. http://api.example.com/v2/resource
            3. There are 2 versions in same endpoint
      2. Custom Request Header
         1. use custom header name
            1. X-API-Version
      3. "Accept" Header
         1. specified in the "Accept" header of the HTTP request
            1. Accept : 1.0
7. Hypermedia as the engine of application state (HATEOAS)
8. Client Concerns
   1. Versionning
      1. New URIs should be used to introduce new concepts
      2. Schemas should be used to manage representational form versions
      3. Entity tags should be used to manage representational state versions
   2. Security
      1. OAuth may be used to protect resources
      2. API management solutions may be used to protect resources
   3. HATEOS
   4. JavaScript related Clients
      1. CORS should be supported to provide multi-origin read/write access
9. Documentations
   1. Proper documentation
      1. Swagger
      2. Azure API Management
      3. Postman
      4. Apigee
   2. Use OpenAPI convension
10. URI Authority Design
    1. Sub domain URI
       1. "api."
          1. https://api.github.com
          2. https://api.twitter.com
          3. https://servicemanagement.googleapis.com
       2. Use Consistent subdomain names like : api
    2. Developer Portal
       1. "developer"
          1. https://developer.twitter.com
    3. Resource Modeling
       1. 4 Resource Archetypes
          1. Document
             1. record
             2. instance
             3. constains
             4. fields
             5. links
             6. includes
             7. decroot
             8. Ex:
          2. Collection
             1. Server-managed
             2. directory
             3. resources
             4. Ex:
          3. Store
             1. Client-managed
             2. resources
             3. repository
             4. Ex:
          4. Controller
             1. procedural
             2. Like
             3. RPC - Remote Procedure Call
             4. Create
             5. Retrieve
             6. Update
             7. Delete
             8. Ex:
11. What is REST API
    1. Representational State Transfer
    2. built on top of the HTTP protocol
    3. architectural style
    4. Main constraints
       1. Client-server architecture
       2. Statelessness
       3. Cacheability
       4. Layered system
    5. Benefits
       1. easy to use and understand and easy to integrate
       2. flexible and can support a variety of data formats
          1. JSON
          2. XML
       3. Stateless : doesn't depend on the state of previous requests.
       4. Efficient: Can use various methods and customisable
    6. Api works like this
12. Resource
    1. REST API Design Rulebook
    2. by Mark Masse