RESTRequest4Delphi: one REST client for Delphi and Lazarus

A builder style client for the Pascal world

RESTRequest4Delphi is an API to consume REST services written in any programming language, designed to facilitate development in a simple and minimalist way, and it supports both Lazarus and Delphi. The language is Pascal, and the licence is MIT.

The API is a builder. A request starts from `TRequest.New`, gains a base URL, gains headers and parameters, declares what it will accept, and is then executed with a verb:

var
  LResponse: IResponse;
begin
  LResponse := TRequest.New.BaseURL('http://localhost:8888/users')
    .AddHeader('HeaderName', 'HeaderValue')
    .AddParam('ParameterName', 'ParameterValue')
    .Accept('application/json')
    .Get;
  if LResponse.StatusCode = 200 then
    ShowMessage(LResponse.Content);
end;

Each call returns the request object, so the calls chain. The result is an `IResponse` interface with a `StatusCode` and a `Content` string, which means the calling code deals with a status code and a body rather than with the HTTP library's own response type. That indirection is what makes the engine choice below possible.

The other verbs follow the same shape. A POST sets the content type and adds a body:

begin
  TRequest.New.BaseURL('http://localhost:8888/users')
    .ContentType('application/json')
    .AddBody('{"name":"Vinicius","lastName":"Sanchez","email":"[email protected]"}')
    .Post;
end;

and a PUT and a DELETE differ only in the URL, the body and the verb at the end of the chain. The body is a plain string in the examples, so the project leaves the decision of how to build JSON to the caller, which is consistent with a library that does not want to own a serialisation stack.

Everything begins with the `RESTRequest4D` unit in the uses clause, and the whole request for a GET fits in a dozen lines, which is the pitch the project makes in its own words: simple and minimal.

Five HTTP engines, chosen with a compiler define

The part of the design that distinguishes this library is that the HTTP layer is not fixed.

By default the components `TRESTRequest`, `TRESTResponse` and `TRESTClient` are used to make requests when using Delphi, and if you use Lazarus the `fphttpclient` components are used by default. Beyond those defaults the project supports five engines to make requests: RESTClient, Synapse, ICS Overbyte, Indy and NetHTTP, and you can change the engine to make requests.

The mechanism is a compiler directive, not a runtime setting. You define `RR4D_INDY`, `RR4D_SYNAPSE`, `RR4D_ICS` or `RR4D_NETHTTP` in the Delphi Compiler conditional defines, and for Lazarus the note is that the `fphttpclient` engine is the default but you can switch to Indy by setting the `RR4D_INDY` directive or to Synapse by setting `RR4D_SYNAPSE`.

That design has an obvious motivation and an obvious cost. The motivation is portability: a project that has to build under both Delphi and Lazarus, or that has to run on a platform where the default components are a poor fit, can change the transport without changing any calling code. The cost is that the choice is made at compile time and baked into the binary, so an application that wants to switch engines at runtime, or that wants to support a platform whose HTTP stack differs, needs separate builds.

It also means the library's surface area is the intersection of what all five engines can do, not the union of what any one of them can do. A Delphi developer reading the documentation will recognise `TRESTClient`, and a Free Pascal developer will find `fphttpclient` waiting for them, which is the point of the whole arrangement.

Adapters that turn a response into data

Adapters allow you to extend the functionality of RESTRequest4Delphi without changing the core of the project, and two are listed as being available from the community.

The dataset adapter loads a DataSet using the DataSet-Serialize library at the time of the request, which means the response body is deserialised into a dataset as part of the call rather than in a separate step:

begin
  TRequest.New.BaseURL('http://localhost:8888/users')
    .Adapters(TDataSetSerializeAdapter.New(FDMemTable))
    .Accept('application/json')
    .Get;
end;

The CSV adapter allows you to generate a text or CSV file with the content of a request, which is a different job again: the response is written out as a file rather than parsed into memory.

Both are separate repositories rather than parts of the core, and that separation is the point of the design. The core library stays small, and a project that needs a DataSet in the response adds one adapter, while a project that needs neither carries no extra code. The cost is that the adapter ecosystem is by definition maintained by the community, and the README describes them as a list maintained by the community rather than a supported set with a compatibility promise.

For a Delphi application that currently hand-rolls a JSON parse into a `TDataSet`, the adapter is the part of this library that removes the most code, because the alternative is the same transformation written out again in every project that needs it.

Credentials set once, applied to every request

Authentication is handled with three methods, and the documented usage is short enough to state in full:

begin
  Request.BasicAuthentication('username', 'password');
  Request.Token('token-type ' + token);
  Request.TokenBearer(token);
end;

The note that follows is the important part for application code: you can set it once and it will be used for every request. So the credential lives on the request object, not on each call site, which is the difference between a library that forces you to pass a token to every method and one that does not.

`BasicAuthentication` takes a username and password, `Token` takes a token with a type prefix, and `TokenBearer` takes the bearer token itself. That covers the three schemes most REST services actually use, and the token type argument in `Token` is passed as a concatenated string, which is a small thing to be aware of if a service expects the type in a header rather than in the credential.

What is not in this list is the rest of the authentication story. There is no mention of a refresh flow, no token storage, no expiry handling and no signing of requests, which is consistent with a library that describes itself as minimal. A client for a service with short lived tokens is expected to own that logic in the application.

Installing through Boss or the search path

There are two documented installation routes, and the choice between them is a question of how the project is managed.

The manual route is to add the following folder to your project, in Project > Options > Building > Delphi Compiler > Search path:

../RESTRequest4Delphi/src

The second route is installation using Boss, the package manager, with a single command:

boss install github.com/viniciussanchez/RESTRequest4Delphi

The repository carries `boss.json` and `boss-lock.json`, so the dependency is described in the format Boss understands, and the project can be installed the same way as any other Boss managed dependency.

For developers there is a second Boss command in the samples section, where the client sample needs the DataSet-Serialize dependency installed with `boss install`, or downloaded manually and added to the search path.

The samples are the most useful part of the repository for a newcomer, and the project is explicit about what they are. Two projects were developed within the examples folder: a client, which is a Windows VCL application consuming a REST API developed in Node.js, and a server-node, a REST server developed with Node.js and Express. The server is run with `npm install` followed by `node server.js`. The repository listing shows more of the same range, with `samples/benchmark/`, `samples/client/`, `samples/console_demo/`, `samples/mercado-libre/`, `samples/server-horse/` and `samples/server-node/`.

A client and a matching server, in two different languages, is a good way to see the library from both ends. The maintainer also sells official training for the library, and the repository has an OpenCollective contributors banner for the code contributions.

The boundary of a small library

What RESTRequest4Delphi is not is as important to an adopter as what it does. It is not a general API client framework. There is no serialisation layer, because the body is a string you build yourself. There is no retry policy, no logging pipeline, no interceptor chain and no request cancellation.

That is a defensible position for a library whose stated goal is a simple and minimalist way to call a REST service, and the multi-engine arrangement is the strongest evidence that the scope is deliberate rather than accidental. A project that needed serialisation and interceptors would not be able to keep five HTTP engines behind a small surface.

The concrete cost for a user is that those pieces have to live in the application. A team with a standard way of talking to its services, with token refresh and with structured logging, will write those on top of this library rather than receive them. A team with a handful of endpoints and a stable API contract will get exactly what it needs.

There is one more thing to weigh, and it is commercial rather than technical. The project is free and open source under the MIT licence, and it also sells official training, and the training link sits in the header of the README. That is a normal arrangement for a library maintained by a professional, and it also tells you where to take questions that the documentation does not answer.

On upkeep, the repository is not archived, the last push was on 2026-10-19, and the release trail shows v4.0.34 on 2026-09-26, v4.0.33 on 2026-09-16 and v4.0.32 on 2026-08-07. The four part version numbers are the kind that a Boss lock file and a build script have to compare carefully, since they are not semantic versions and a naive comparison will order them wrongly.

Editorial conclusion

RESTRequest4Delphi suits a Pascal developer who has to call a REST service from a Delphi or Lazarus application and wants one API across both compilers, with the option to change the HTTP engine or to read a response straight into a DataSet. It does not suit a team that needs a full API client framework with serialisation, caching and interceptors, since the project is scoped to being simple and minimal. Before adopting, check that the engine you need is covered, since the choice is fixed at compile time through a conditional define, and remember the project also sells paid training, which tells you where the maintainer expects questions to go.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. viniciussanchez/RESTRequest4Delphi on GitHub