Why Developers Favor GET & POST Over PUT/DELETE: A Practical Look at RESTful APIs

In a previous tutorial we discussed how to develop Web APIs, and readers pointed out issues such as OpenAPI and opinions on Thrift.

We call them “Web APIs” because the error information is reflected in the HTTP response body; some errors are returned by the web server rather than the API itself. For pragmatic reasons we often return JSON or XML in the body, which many teams do without problems, even though it is not a pure RESTful design but rather a JSON API.

HTTP Basics

The HTTP protocol defines request methods (GET, POST, PUT, DELETE, HEAD, TRACE, OPTIONS), headers, and body. Typically servers implement the first four methods. GET, POST, PUT, DELETE correspond to the four CRUD operations: read, create, update, delete.

According to the specification, GET is safe and idempotent, meaning it should only retrieve information without modifying server state, similar to a database query. Idempotent means multiple identical requests yield the same result.

In practice many developers use GET and POST for all CRUD actions, avoiding PUT and DELETE because GET is simpler and POST requires form handling, which can be cumbersome during testing.

Frameworks also influence this behavior; some MVC frameworks treat URLs merely as actions rather than abstract resources, supporting only GET and POST.

RESTful Overview

REST (Representational State Transfer) was defined by Roy Fielding in 2000 as an architectural style for distributed systems. It is not a strict standard, but its typical characteristics include:

Human‑readable URL structures.

Data representation in JSON or XML.

Use of explicit HTTP methods (GET, POST, PUT, DELETE).

Stateless client‑server interactions.

Scalable and loosely coupled design.

Client‑maintained session state.

Conclusion

This article attempts a “scientific” description of RESTful concepts, acknowledging that it is not exhaustive. Feedback is welcome for further discussion. The next part will demonstrate a practical implementation of a runnable RESTful API.