# Overview A design philosophy applied to [[HTTP(S)]] communications that focuses on server resources and limits the set of methods to those based on HTTP methods to access resource (GET, POST, PUT, DELETE). An API that follows REST is known as a RESTful API. # Key Considerations ## Naming Conventions Tips and tricks for good REST naming conventions #flashcard - Use plural nouns for the names of resources - Use proper resource hierarchy, where possible - `/bussinesses/{businessId}/reviews` - Don't build out unnecessary path segments; you do not need to show your whole hierarchy in the API - Use strings for all identifiers <!--ID: 1751507777156--> ## Commands | Command | Description | Pros | Cons | Use Cases | | ---------- | ------------------------------------------------ | ---- | ---- | --------- | | [[GET]] | Request data from the server; do not have a body | | | | | [[PUT]] | Update data on the server | | | | | [[POST]] | Send data to the server | | | | | [[DELETE]] | Delete data from the server | | | | | [[PATCH]] | Update a resource partially | | | | ## Status Codes ** - 3XX - Redirectional Status Codes - 301 - Permanent Redirect - Indicates the resource has been permanently moved to the target URL. Browsers typically caches this response, which would result in skipping reaching out to the original URL's server in subsequent interactions. - 302 - Temporary Redirect - Indicates the URL is temporarily located at a different URL ## Versioning A common approach for versioning is to use a version number in the URL or in the HTTP `Accept` header. # Pros - Standardized, which means it is supported by all mainstream programming languages and has a vast ecosystem of tools available - Good for experimentation and debugging # Cons - May provide redundant data # Use Cases # Related Topics - There is a definition format for REST defined as [[OpenAPI or Swagger]]