Compare
REST vs. Graftcode

No controllers. No DTOs. Just methods.

REST works everywhere, but ties your API to HTTP routes, methods, status codes, controllers, and DTOs. Graftcode turns ordinary public methods directly into a strongly typed client without HTTP-specific dependencies.

[T]TRY IT FREE [F]FULL COMPARISON

/USED BY LEADING COMPANIES

/AT GLANCE

REST vs Graftcode

REST made HTTP the universal contract for APIs. Graftcode makes ordinary public methods directly callable across services like never before.

Universal — every language and tool speaks HTTP
...but you write controllers, routes and DTOs
Real end-to-end types need OpenAPI + codegen
Errors map to HTTP status codes on both sides
No config-driven remote switch; no native MCP

Strongly typed, remote calls - across 143 technology pairs
Expose pure classes and public methods
Install always up to date - strongly typed client (Graft) as a normal npm / NuGet / pip / packagist / rubygems dependencies
In-process ↔ remote is a config switch, not a rewrite
Public methods become MCP tools automatically

/WHY SWITCH

Three reasons teams move from REST

REST ties APIs to HTTP contracts and integration code. Graftcode connects ordinary public methods across any technology, with interchangeable communication channels and no integration code to maintain.

A method call replacing a REST controller and DTO

No controllers, no DTOs

REST requires you to bind your code to routes, DTOs, and HTTP status codes. With Graftcode, you simply write a public method and it's ready to be called remotely from almost any technology. It can't get any simpler.

A typed Graft that refreshes without an OpenAPI codegen step

Types without codegen drift

REST is strongly-typed over the wire; real types mean an OpenAPI spec and a codegen step that drifts. Graftcode ships a typed Graft that auto-refreshes.

Caller packages updating when a method signature changes

No cascading changes

With REST, changing an API can mean updating controllers, routes, DTOs, and clients. With Graftcode, you simply change or add a public method, refresh the package, and call it remotely just like a local function. No cascading updates across integration layers.

[F]FULL COMPARISON

/SHOW, DON'T TELL

Same call. Controller + client vs a method

Fetching one user — the REST plumbing vs a direct typed call.

REST

controller + route + DTO

[ApiController]
public class UsersController : ControllerBase {
  [HttpGet("/users/{id}")]
  public ActionResult<UserDto> Get(int id) =>
    _db.Find(id).ToDto();
}

client: fetch + handle status code & define DTOs

interface UserDto {
  id: number;
  name: string;
  email: string;
}

async function getUser(id: number): Promise<UserDto> {
  const response = await fetch(`/api/users/${id}`, {
    method: "GET",
    headers: {
      Accept: "application/json",
    },
  });

  if (response.status === 404) {
    throw new Error("User not found");
  }

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }

  return (await response.json()) as UserDto;
}

const user = await getUser(42);

GRAFTCODE

expose a class

public class UserService {
  public User GetUser(int id) => _db.Find(id);
}

Install the Graft & call

from acme_user_service import UserService

user = UserService.get_user(42)

Same call, fully typed.REST needs a controller, a DTO and a client - Graftcode needs a method.

/FEATURE MATRIX

The honest, line-by-line comparison

CapabilityREST

PROGRAMMING MODEL

Call with Strongly Typed Methods

[×] NO

Regular Exception support

[×] NO

Complex DTOs & arrays passed by value in one call

[✓] YES

PROGRAMMING DEPENDENCIES & CONTRACTS

No additional SDK

[-] PARTIAL

No contract files

[×] NO

Use remote modules as dependencies

[×] NO

TOPOLOGY & TRANSPORT

Switch between WebSocket, HTTP/2, TCP, queues, events, or PaaS channels with a single env var.

[×] NO

Switch remote <-> in-memory with config only

[×] NO

TOPOLOGY & TRANSPORT

Same programming model for queues / event buses

[×] NO

Full streaming

[-] PARTIAL

Expose methods are immediately callable via MCP

[×] NO

REST compared with Graftcode
Capability	REST	Graftcode
PROGRAMMING MODEL
Call with Strongly Typed Methods	[×] NO	[✓] YES
Regular Exception support	[×] NO	[✓] YES
Complex DTOs & arrays passed by value in one call	[✓] YES	[✓] YES
PROGRAMMING DEPENDENCIES & CONTRACTS
No additional SDK	[-] PARTIAL	[✓] YES
No contract files	[×] NO	[✓] YES
Use remote modules as dependencies	[×] NO	[✓] YES
TOPOLOGY & TRANSPORT
Switch between WebSocket, HTTP/2, TCP, queues, events, or PaaS channels with a single env var.	[×] NO	[✓] YES
Switch remote <-> in-memory with config only	[×] NO	[✓] YES
TOPOLOGY & TRANSPORT
Same programming model for queues / event buses	[×] NO	[✓] Via plugins
Full streaming	[-] PARTIAL	[-] PARTIAL
Expose methods are immediately callable via MCP	[×] NO	[✓] YES

/BY THE NUMBERS

The payoff, in numbers

60%

less code for AI to touch

1/8

of CPU usage comparing to REST or gRPC

coding languages supported

package managers supported

/FAQS

Before you ask

REST is widely supported, but it ties APIs to HTTP-specific contracts, routes, DTOs, and status codes. Graftcode removes these constraints for both public APIs and internal services. Simply expose ordinary public methods and let consumers install a strongly typed client through their existing package manager. No special SDK, license, or shared codebase required. The same methods can be accessed across languages and communication channels without changing their implementation.

/COMMUNITY

Join grafters community

Many developers are loving Graftcode and what it brings to them.

“Graftcode appears to be an exceptionally useful platform. Its key value proposition is allowing developers to concentrate on core business requirements instead of tedious service integration tasks. I believe the concept of beginning with a monolithic structure and then having the option to dynamically transition to a microservice architecture will prove to be extremely valuable.”