Why Enums Should Be Avoided in RPC Interface Parameters and Return Values

In a production environment an IllegalArgumentException was thrown because the enum AType in a downstream library added a new constant P_M that the consuming service had not upgraded to, leading to a deserialization failure during an RPC call.

The issue was reproduced by defining a shared library with an interface AFacadeService returning an AResponse containing an AType field. Service A upgraded the library to include P_M, while Service B kept the old version, causing the RPC framework to attempt Enum.valueOf on a missing constant and throw the exception.

The root cause lies in most RPC frameworks serializing responses to JSON and deserializing them back to Java objects; during deserialization the Enum.valueOf method throws an IllegalArgumentException when the enum constant is absent.

According to the Alibaba Java Development Manual, enums should be used for request parameters but not for return values, reflecting the same compatibility concerns described above.

Extended analysis argues that while enums help validate input and document allowed values, they create tight coupling: any change in a shared library forces all downstream services to upgrade, which is often impractical for large ecosystems with many callers.

The author therefore recommends replacing enum fields in RPC interfaces with plain String types, documenting the allowed values via Javadoc @see references, thus avoiding deserialization errors and reducing dependency constraints.

Overall, the article advises minimizing the use of strong‑typed enums in both request and response payloads of public RPC APIs to achieve better backward compatibility and easier evolution of services.