AI Translated Document

This document was translated using an AI translation tool.
Due to the nature of AI translation, some sentences or terms may be interpreted differently from the original intent.
There may be mistranslations or inaccuracies, so please refer to the original text or consider additional review if accuracy is critical.
Your suggestion for a better translation would be highly appreciated.

Original Document in Korean

Don't Use Restful So Blindly¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com) 
Draft: December 2024 / Revision: January 2026

[Author’s Intent] This article logically demonstrates that RESTful architecture is not a panacea for all business systems, and warns that architecture should be chosen carefully according to the nature and requirements of each system.

Executive Summary¶

Currently, RESTful API is regarded as the de facto standard in development. (specially in Korea)
As it has become the de facto standard, RESTful API is being used indiscriminately without consideration of its limitations and costs.
RESTful was proposed to maximize the scalability and interoperability of the web, and is an architectural style mainly for distributing resources (=Data) statically.
The requirements for Uniform Interface, Statelessness, and Cacheability imply such a purpose.
Providing operations only through GET/POST/PUT/PATCH means treating all resources as equivalent concepts (essentially JSON documents).
Forcing RESTful principles such as Statelessness and Cacheability on JSON documents on the web essentially converges to static (persistent/semi-persistent) document sharing.
Therefore, it is inappropriate for business systems where transactions—simultaneous editing of multiple resources—are central.
Designing CRUD resources to correspond to individual URIs fragments complex scenarios into dozens of HTTP calls.
However, the explosion of round trips is a minor issue; the bigger problem is that the client is forced to guarantee the atomicity of transactions.
This is a very serious vulnerability in terms of software reliability and security.
Moreover, most businesses are not compatible with Statelessness.
The web’s origin was document sharing within CERN (European Organization for Nuclear Research)—essentially a free concept, but business is centered on state, rules, and transactions.
The existence of sellers, buyers, products, and prices makes the existence of 'state' essential.
As a result of analyzing architectural advantages/cost structures, RESTful is a structural solution assuming systems with very rare modifications to flat information structures such as wikis, communities, and ledgers.
Applying this to fields such as e-commerce, logistics, education/learning management, machinery, sales, and customer management, where state changes continuously, only leads to an explosion of costs.

Preface¶

Currently, in the Korean web development ecosystem, RESTful API has firmly established itself as a 'default' and 'de facto standard' beyond the realm of choice. In architecture meetings for new projects, alternatives to REST are often not even seriously considered when discussing communication methods. It is almost an unwritten rule that if you are doing web development, you must design HTTP APIs that exchange JSON in a RESTful way.

For developers tired of the excessive complexity of SOAP and XML, which once dominated the enterprise market, the intuitiveness and simplicity of REST were certainly attractive alternatives. However, over time, this 'simplicity' has become a barrier to architectural thinking. Countless development teams mechanically follow the act of specifying resources in URLs and mapping CRUD to HTTP methods, calling it 'RESTful', without deeply considering why REST’s essential constraints—Statelessness, Cacheability, HATEOAS, etc.—are necessary and what costs they entail.

The problem arises when this habitual choice conflicts with the essence of the business we need to solve. REST is inherently an architectural style optimized for the web—a vast distributed hypermedia system—designed to deliver and share the state of static documents or resources. However, many modern business applications go beyond simple listing and retrieval of information, requiring complex transaction control, state transitions, and sequential, atomic business logic processing at their core.

Forcibly fitting these dynamic business requirements into the static, resource-centric REST architecture inevitably leads to inefficiency. Dozens of network round trips occur to process a single logical operation, the client takes on the responsibility for transactions that the server should handle, and unnecessary complexity seeps into the code everywhere to ensure data consistency. Nevertheless, when asked, "Why are you using REST for this project?", the only answers are complacent ones like "Because it’s the industry standard" or "Because there are many libraries", rather than technical justifications.

This article does not claim that RESTful APIs are worthless or should be unconditionally rejected. Rather, it points out the structural risks brought by the current trend of using REST for everything without thought, and the indiscriminate adoption without considering the characteristics and cost structure of the tool. If the system we are building is not a simple blog or wiki, REST may not be the best answer. Now is the time to break away from habitual choices and coolly weigh the architecture that can most effectively control the complexity of the problems we face, along with its costs and benefits.

REST is a Style for Document Distribution¶

REST was first proposed in 2000 in Roy Fielding’s doctoral dissertation. REST is based on the following six constraints for designing distributed systems. These constraints define the REST architectural style, and only by adhering to them can a system be truly called RESTful.

Client-Server Architecture: Clearly separates client and server so each can focus on its own role.
Statelessness: The server does not store client state information. Each request must be processed independently, and all necessary information must be included in the request.
Cacheability: Server responses must be cacheable, and clients can use this to reduce network traffic and server load.
Layered System: Multiple layers can be placed between client and server, and each layer operates independently.
Uniform Interface: REST systems must provide a consistent interface through which resources can be interacted with.
Code on Demand: The server can send code to the client for execution as needed. E.g., JavaScript, plugins, etc.

If you look deeply into REST’s constraints, especially Uniform Interface, Statelessness, and Cacheability, the architectural intent becomes clear. That is, 'efficient distribution and sharing of information'.

First, let’s look at Uniform Interface. REST limits resource manipulation to a very restricted set of HTTP methods (GET, POST, PUT, DELETE, etc.). This is a declaration to abstract everything the system handles as equivalent concepts of 'documents' or 'resources'. Instead of defining unique methods for complex business actions (e.g., 'approve order', 'reserve inventory', 'start shipping'), it reduces them to simply creating or updating documents. This is similar to how Linux systems fundamentally try to reduce everything to file I/O, and even if the data is generally in JSON format, it essentially follows the metaphor of static document management.

Next, Statelessness and Cacheability strongly suggest that this architecture is optimized for 'unchanging' or 'rarely changing' information. The fact that the server does not need to remember the client’s previous state means each request is like an independent document retrieval. Also, the ability to cache responses assumes that data does not change rapidly over time and that it is fine for multiple users to see the same data at the same time.

The web itself is such a system. News articles, blog posts, Wikipedia entries, etc., once written, rarely change, and it’s not a problem for many people to read them simultaneously. REST was designed to maximize the scalability and interoperability of such a web.

But what about the modern business applications we develop? Inventory changes in real time, order status transitions according to complex rules, and server responses must change depending on the user’s context. Forcing REST principles on JSON data in such dynamic environments is no different from treating living business processes as static, taxidermied documents.

As a result, RESTful is an architectural style for statically distributing and sharing data called resources. Uncritically applying this to business systems where complex transactions and state management are essential is a fundamental misunderstanding of the tool’s purpose, like trying to build a complex ERP with Excel.

RESTful Does Not Accommodate Transactions¶

RESTful is inappropriate for business systems where transactions—simultaneous editing of multiple resources—are central. To be precise, there is no place for transactions at the core of RESTful Architecture, so they are not accommodated. As a result, this must be handled outside the architecture, and the responsibility shifts from the reliable server to the client.

REST assumes "independent manipulation of resources". When an order occurs, in reality, payment approval, inventory deduction, point accrual, coupon consumption, and shipping address confirmation are bundled into a single atomic state transition. But with REST design, each is broken down into the creation/modification of different resources, and each step is scattered across different endpoints. At this point, atomicity is decomposed into a set of HTTP calls. A single business command is split into dozens of requests, and the number of failure combinations increases exponentially. The logic to determine "how far succeeded" and to roll back is ultimately borne by the client or orchestrator. However, most do not create orchestrators or transaction managers.

Designing CRUD for resources to correspond to individual URIs is not user scenario-friendly. It is a design focused on data management. As a result, a single function is fragmented into dozens of HTTP calls. The explosion of round trips is a minor issue; the bigger problem is that the guarantee of transaction atomicity is left to unreliable external parties (e.g., web browsers). For example, if inventory deduction fails after payment approval, a payment cancellation must be called, and if that also fails, a "compensation for the compensation transaction" must be created. This structure reduces the server from a reliable system to a mere entity store. Ultimately, the core of business logic is shifted to the client.

This is not just a matter of complexity, but of reliability and security. The core of a transaction is the guarantee that "intermediate states are not exposed externally", but splitting with REST exposes intermediate states between API calls. At that moment, concurrency conflicts occur, and users experience failures like "payment succeeded but order failed". More fatally, it increases the attack surface. Changing the order of calls or re-executing only some steps can create loopholes such as duplicate discounts, inventory bypass, and duplicate point accrual. Security ultimately means creating rules to verify the order and number of API calls, which destroys the simplicity of REST.

In reality, many teams work around this with the "Saga pattern" or "compensating transactions". But this does not eliminate transactions; it re-implements them in a much more complex form. Distributed locks, message queues, state stores, and retry strategies are added, and operators must monitor failure combinations. Ultimately, the architecture becomes more expensive, and failure response becomes more difficult. In summary, RESTful does not eliminate transactions. It merely pushes the handling of transactions from the server to the client and operations. This is the biggest reason REST feels inefficient in complex business systems.

Most Business Is Not Ledger Keeping¶

Most business systems are fundamentally incompatible with the Statelessness assumed by RESTful. The web’s origin was document sharing within CERN, i.e., an environment for free information distribution and viewing. At that time, the web’s purpose was the distribution and sharing of static documents, each document existed independently, and user actions did not change the system’s state. But business systems have the opposite characteristics. Sellers, buyers, products, and prices are not just information, but sets of interrelated states, rules, and transactions.

For example, consider an e-commerce system. The process of a user adding a product to a cart, going through payment, and confirming an order is not a simple combination of CRUD. At each stage, complex business logic such as inventory changes, payment approval, shipping address validation, and discount policy application is involved. All the data generated in this process is closely connected, and atomicity is required so that if one operation fails, the whole must be rolled back. In other words, a transaction is not just storing and retrieving documents, but a complex flow where multiple states change organically and those changes must be kept consistent.

RESTful’s Statelessness enforces the constraint that each request must be processed independently. The server does not remember the client’s previous state, and all information must be included in the request. As a result, in real business, state is stored in various ways such as client tokens, temporary storage, and distributed caches. For example, cart IDs, payment sessions, authentication tokens, etc., must be sent with every request, and this process adds additional complexity such as security verification, validation, and concurrency control. Ultimately, state is not eliminated, but replicated across more layers, increasing management points.

Furthermore, the essence of a transaction is reliability and consistency. Bank transfers, inventory management, order processing, etc., all require a flow where "multiple rules are evaluated in a single command, and the whole is rolled back on failure". But if RESTful is applied by the book, a single business step is split into multiple HTTP calls such as 'create order → register payment info → deduct inventory → confirm shipping address'. Each call must be checked for independent success, and if it fails, another API must be created and called to roll back. Ultimately, the API is not a state machine but just an entity store, and the actual flow is scattered in client code. As the client takes on the guarantee of atomicity, the number of failure combinations and recovery scenarios increases rapidly. The more clients there are, the more uncontrollable combinations arise, and the server cannot guarantee transactions.

These structural limitations directly affect security and reliability. For example, if transaction atomicity is broken in a payment system, fatal problems such as duplicate payments, inventory errors, and data inconsistencies can occur. RESTful’s Statelessness makes it difficult to implement server-side controls to prevent such problems, shifting excessive responsibility to the client. Also, when network failures or delays occur, it is common for only some of multiple requests to succeed or fail, and recovery logic is redundantly implemented on both client and server.

In the end, a transaction is not just document management. The essence of business is the change of state, the consistency of that change, and the reliability of transactions. Uncritically applying RESTful’s constraints is to misunderstand complex business as simple ledger keeping. We must first understand the purpose and requirements of the system and choose the architecture accordingly.

RESTful Is Very Flat¶

Another essential limitation of RESTful architecture is its 'flatness'. RESTful is most effective in environments where entities have little dependency on each other and each resource exists independently, such as wikis, communities, and ledgers. In such systems, each resource is clearly identified by a single URI, and CRUD operations are simply mapped. However, real business domains usually involve complex entity relationships, hierarchical structures, and various dependencies.

The concepts of Fan-in and Fan-out are useful for explaining this. Originally, Fan-in and Fan-out are used for module dependencies, but data and information are also connected for various reasons such as association, reference, dependency, and extensibility.

Since RESTful treats each resource independently, as Fan-in/out increases, the problem of deciding how much data a single resource should return arises in a chain. For example, if only the customer ID is returned when querying customer information, additional calls for orders, payments, shipping, etc., for sub-resources are needed in a 1+N+M+L... pattern. Conversely, returning all sub-resources at once causes unnecessary traffic and blurs the identity of the resource (i.e., what is the core data).

These limitations of flatness lead to various problems in real systems. First, in domains with complex data relationships, RESTful’s simple resource-URI mapping causes inefficiency. For example, when querying order history in an e-commerce system, not only the order itself but also products, payments, shipping, discounts, coupons, and many related entities are needed. If each entity is separated into its own URI, the client must make dozens of network calls, leading to performance degradation, synchronization issues, and increased points of failure. Second, returning all sub-resources at once causes data over-transmission, unnecessary information exposure, and reduced API consistency. In reality, each client needs a different range of data, so returning all information uniformly undermines RESTful’s simplicity.

Also, in domains with large Fan-in/out data structures, API design becomes much more difficult. Decisions must be made about how much related data to include at each URI, how to set nesting depth and return policies, and how to support partial updates or partial queries.

Ultimately, RESTful is truly valuable where data structures are simple, entity dependencies are weak, and each resource can be managed independently. Conversely, in systems with complex business logic, hierarchical data, and various relationships and dependencies, RESTful’s flatness becomes a limitation.

The Pros, Cons, and Bill of RESTful as Architecture¶

As an architecture, RESTful is a structural solution designed with systems in mind where data changes infrequently and there are almost no transactions or complex state transitions. In such environments, RESTful’s simplicity, consistency, and scalability are maximized. For example, in systems like wiki documents, bulletin board posts, or ledger records, where most operations are queries and simple additions/edits, and multiple users do not cause complex state changes simultaneously, RESTful’s standardized interface and caching strategies are highly effective. Also, in document-based systems where each resource exists independently, the constraint of Statelessness can actually contribute to system simplification and scalability.

However, in real business systems—especially in fields like e-commerce, logistics, education/learning management, machine control, sales, and customer management, where state changes continuously and complex transactions, rules, and concurrency control are essential—applying RESTful as is leads to serious inefficiency and increased costs. In such systems, a single business command changes multiple states at once, and atomicity and consistency are required so that the whole can be rolled back on failure. But because RESTful requires each request to be processed independently, complex business flows are split into multiple HTTP calls, and the responsibility for transactions is shifted to unreliable clients. The resulting network costs, state synchronization issues, complexity of compensating transactions, data inconsistencies, and security vulnerabilities seriously undermine the reliability and maintainability of the entire system.

In particular, the biggest limitation of RESTful is that it is optimized for "information structures that rarely change". In other words, it does not provide or only rarely provides features that change over time. That is, it is optimized for very passive systems with almost no active actions.

Conclusion¶

RESTful remains a powerful tool for simple information distribution and retrieval, and for flat data structures with infrequent changes, but it is not suitable for systems where state, transactions, and complex business logic are central.

Every architecture must be chosen after reviewing the accompanying benefits and costs to select the best fit for the current problem. Otherwise, the risk will be paid as overtime and increased labor costs during development, and as system instability during operation. Therefore, the current state where RESTful API is recognized as the 'de facto standard' in the web development ecosystem is like most developers and companies paying unnecessary taxes without knowing the reason.

The choice of architecture must start with recognizing its strengths and weaknesses, and the costs you are willing to pay for them. Then, you must make an appropriate choice according to the essence and requirements of your problem. In the same vein, RESTful is not a panacea but a tool optimized for specific problems, and it should not be regarded as the 'default' whenever possible.

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University