REST Architectural Style Quiz

REST Architectural Style

• REST (Representational State Transfer) is an architectural style for designing networked applications. It was introduced by Roy Fielding in 2000.
• RESTful refers to web services or APIs that adhere to the principles and constraints of REST.
• REST defines a set of constraints and principles for creating web services that are scalable, simple, and stateless.
• REST is commonly used over HTTP.

Statefulness and Statelessness

• Statelessness means each request is independent of any other. The server does not store information about previous requests.
• Statefulness means the server retains information about the client across multiple requests.

HTTP Methods

• HTTP methods are used to indicate the purpose of the request and what is expected if the request is successful.
• HTTP methods are also referred to as HTTP verbs.
• Each method has its own semantics.

Common HTTP Methods

• POST: submits an entity to a specified resource, often causing a change in the server's state. It is not idempotent or cacheable, and it is unsafe.
• GET: requests a representation of a resource. It is idempotent, safe, and cacheable.
• PUT: replaces all current representations of a resource with the request content. It is idempotent, not cacheable, and unsafe.
• DELETE: deletes a resource. It is idempotent, not cacheable, and unsafe.
• HEAD: requests the headers of a resource, similar to GET but without the body. It is idempotent, safe, and cacheable.
• CONNECT: establishes a tunnel to a server. This method is primarily used by web proxies.
• OPTIONS: describes the communication options for the target resource. It is safe and cacheable.
• TRACE: performs a message loop-back test. It is safe and cacheable.
• PATCH: applies partial modifications to a resource. This method allows clients to modify specific parts of a resource without replacing the entire resource. It is not idempotent, not cacheable, and unsafe.

HTTP Response Status Codes

• Indicate whether an HTTP request has been completed successfully.
• Responses are grouped into five classes: Informational, Successful, Redirection, Client Error, and Server Error.
• 100 - 199: Informational responses, typically used to indicate that the server has received the request and is processing it.
• 200 - 299: Successful responses, indicating that the request was successfully processed.
• 300 - 399: Redirection messages, instructing the client to try a different URL.
• 400 - 499: Client error responses, indicating that there was an error on the client's side (e.g., invalid request).
• 500 - 599: Server error responses, indicating that there was an error on the server's side (e.g., internal server error).

URI - Uniform Resource Identifier

• A string of characters used to identify a resource on the internet.
• URIs enable interaction with resources over a network (e.g., the World Wide Web) using specific protocols.
• They provide a way to access and locate resources.

URI Components

• scheme: specifies the protocol used (e.g., http, https, ftp).
• authority: includes the domain name and optionally the port (e.g., www.example.com, user@host:8080).
• path: specifies the location of the resource on the server (e.g., /path/to/resource).
• query: provides additional parameters (e.g., ?key1=value1&key2=value2).
• fragment: indicates a specific part of the resource (e.g., #section1).

URI Types

• URL (Uniform Resource Locator): A subset of URIs that provides a means of accessing a resource by specifying its location on a network (e.g., https://www.example.com/index.html)
• URN (Uniform Resource Name): A subset of URIs that provides a unique name for a resource without implying its location or access mechanism (e.g., urn:isbn:978-3-16-148410-0).

Uses of URIs

• Web browsing: URLs are used to locate web pages and resources.
• APIs: URIs are used to access endpoints in RESTful APIs.
• Email: Mailto URIs specify email addresses.
• File access: File URIs specify file paths.

Best Practices in Making URIs for RESTful Web Services

• Use nouns to represent resources (e.g., /users instead of /getUsers).
• Use plural nouns for resource collections (e.g., /users, /orders).
• Reflect resource hierarchy and relationships in the URI structure (e.g., /users/{userId}/orders).
• Map CRUD operations to HTTP methods: GET for retrieving resources, POST for creating resources, PUT for updating resources, and DELETE for deleting resources.
• Use query parameters for filtering, sorting, and pagination (e.g., /users?sort=desc, /products?category=electronics&price_lt=100).
• Use hyphens to improve readability (e.g., /user-profiles).
• Avoid file extensions in URIs.
• Use resource nesting sparingly.
• Version your API.
• Use consistent resource names.