Curious What Replaces REST?

Graftcode argues that many service integrations can replace REST’s route-and-DTO model with direct calls to ordinary public methods. In its example, REST requires a controller, endpoint, data-transfer object, and client code to fetch a user; Graftcode exposes a service method and lets a consumer call it through an installable, strongly typed package. The pitch is that this avoids maintaining HTTP-specific controllers, status-code handling, contract files, and generated clients, while reducing mismatches when method signatures change. Graftcode says its packages refresh automatically and work across different programming languages and package managers, so services need not share a codebase.

The comparison presents REST’s universality and broad tooling support as strengths, but says HTTP contracts make it cumbersome for internal services and harder to move between deployment arrangements. Graftcode claims teams can switch between in-process and remote calls through configuration, choose among transports such as HTTP/2, WebSockets, TCP, queues, events, or platform channels, and expose methods as MCP tools. Its feature matrix also advertises regular exception handling, remote modules as dependencies, and queue or event support through plugins; both approaches are described as having only partial support for full streaming. The page reports 20 supported languages and 10 package managers, and claims 60% less code for AI to handle and one-eighth the CPU usage of REST or gRPC. Overall, it promotes Graftcode as a way to reduce integration work, while retaining REST’s established role where universal HTTP compatibility matters.