how-api-works

Understanding REST: Architecture, HTTP Methods, Status Codes, and Key Differences from SOAP

What is Rest?

Roy Fielding, a key contributor to the development of REST (Representational State Transfer), defines it as an architectural style for distributed hypermedia systems.

According to Leonard Richardson and Sam Ruby in “RESTful Web Services,” REST is an architectural style that is defined by a set of constraints. (Richardson & Ruby, 2007).

Martin Fowler defines REST as an architectural style that uses a stateless communication protocol, typically HTTP, for building scalable web services (Fowler, 2003).

With these definitions, we can understand that REST is an architectural style for designing networked applications that defines rules to achieve performance, scalability, simplicity, modifiability, visibility, portability, and reliability.

Brief History

REST was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation, the dissertation topic was “Architectural Styles and the Design of Network-based Software Architectures”. Fielding, one of the principal authors of the HTTP specification, proposed REST as a way to guide the design and development of the architecture for the web. Since then, REST has become the standard for building web services due to its simplicity and scalability.

Architectural Constraints

The six main constraints of REST architecture enhance system architecture by providing benefits in performance, scalability, simplicity, modifiability, visibility, portability, and reliability.

  • Client-Server Architecture: Separates concerns between the client and server to improve portability, scalability, and independent evolution of components.
  • Statelessness: No client context is stored on the server between requests; each request contains all necessary information. Session state is maintained in the client, promoting scalability and supporting multiple organizational domains.
  • Cacheability: Clients and intermediaries can cache responses to improve performance and scalability. Responses define themselves as cacheable or not to prevent stale data.
  • Layered System: Intermediaries can be transparently added between clients and servers. This enhances scalability, security, and allows for added functionalities without affecting client-server interactions.
  • Code on Demand (Optional): Servers can extend client functionality by transferring executable code, such as Java applets or JavaScript, enhancing flexibility.
  • Uniform Interface: Defines a consistent way for clients and servers to communicate, promoting simplicity and scalability across different APIs.

HTTP Methods

HTTP methods, also known as HTTP verbs, are request methods used to specify the desired action to be performed on a given resource in a web application. The most common HTTP methods, which are often used to perform CRUD (Create, Read, Update, Delete) operations, include:

  • GET: Retrieves data from the server.
  • POST: Sends data to the server to create a new resource.
  • PUT: Updates an existing resource on the server or creates a new resource if it does not exist.
  • DELETE: Removes a resource from the server.
  • PATCH: Partially updates an existing resource.

HTTP Status Codes

The HTTP status codes are issued by the server in response to a client’s request made to the server. According to RFC9100, they are classified into five distinct categories:

  • Informational (100–199): Request received, continuing process.
  • Success (200–299): The request was successfully received, understood, and accepted.
  • Redirection (300–399): Further action needs to be taken to complete the request.
  • Client Error (400–499): The request contains bad syntax or cannot be fulfilled.
  • Server Error (500–599): The server failed to fulfil a valid request.

Key Differences Between REST and SOAP for Web Services

REST (Representational State Transfer) and SOAP (Simple Object Access Protocol) are both communication protocols used in web services, but they differ significantly in their approach:

  • Protocol Style: REST is an architectural style based on standards like HTTP and URLs, emphasizing simplicity and statelessness. SOAP is a protocol that defines a strict messaging framework with XML-based formats.
  • Message Format: REST typically uses JSON or XML for data exchange, while SOAP relies exclusively on XML.
  • State: REST is stateless, meaning each request from a client to the server must contain all necessary information. SOAP can maintain state between requests using context.
  • Interface: REST uses standard HTTP methods (GET, POST, PUT, DELETE) to perform actions on resources. SOAP defines its own set of standards for message format and service interfaces.
  • Flexibility: REST is more flexible and simpler to implement, making it ideal for mobile and web applications. SOAP is more rigid and often used in enterprise-level applications requiring strict security and reliability.
  • Usage: REST is widely adopted for its simplicity and compatibility with various platforms and devices. SOAP is still used in scenarios requiring strong protocol-level reliability and formal contracts between services.

Bye!

Thank you for reading. Feel free to comment and add aspects that you consider important but were not covered here. Thanks🫂

References

Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures (Doctoral dissertation, University of California, Irvine).

Richardson, L., & Ruby, S. (2007). RESTful Web Services. O’Reilly Media.

Fowler, M. (2003). Patterns of Enterprise Application Architecture. Addison-Wesley Professional.

HTTP Working Group. (2022). RFC 9110 — Overview of HTTP Status Codes. Retrieved from https://httpwg.org/specs/rfc9110.html#overview.of.status.codes

REST API Tutorial. (n.d.). Introduction to REST API. Retrieved from https://www.restapitutorial.com/introduction

Mozilla Developer Network. (n.d.). HTTP Status Codes. Retrieved from https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Wikipedia. (n.d.). Representational State Transfer. Retrieved from https://en.wikipedia.org/wiki/REST

Mozilla Developer Network. (n.d.). HTTP Methods. Retrieved from https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

Geeks for Geeks. (n.d). What is Rest API in Node JS. Retrieved from https://www.geeksforgeeks.org/what-is-rest-api-in-node-js/

One reply on “Understanding REST: Architecture, HTTP Methods, Status Codes, and Key Differences from SOAP”

  • […] this article, you will know exactly which one to choose.In our previous articles, we explored SOAP, REST, and even built a RESTful API with Python and Django REST Framework. As a result, we saw how REST […]

Leave a Reply

Your email address will not be published. Required fields are marked *