Como Consumir API REST no Delphi: Guia Completo com JSON, GET, POST e Autenticação

terça-feira, 15 de setembro de 2026 • Kléber Almeida

Como Consumir API REST no Delphi: Guia Completo com JSON, GET, POST e Autenticação

As APIs REST estão presentes praticamente em todos os tipos de sistemas modernos.

Aplicações comerciais, sistemas financeiros, plataformas de pagamento, serviços de mapas, sistemas de emissão fiscal, plataformas de comunicação e aplicações mobile normalmente precisam conversar com outros sistemas através de APIs.

Para quem desenvolve em Delphi, consumir uma API REST é uma tarefa relativamente simples quando utilizamos os recursos disponíveis no próprio Delphi.

Neste artigo vamos construir, passo a passo, uma estrutura profissional para consumir APIs REST utilizando Delphi, trabalhando com:

  • REST API;
  • HTTP;
  • GET;
  • POST;
  • PUT;
  • DELETE;
  • JSON;
  • Headers;
  • Query Parameters;
  • Bearer Token;
  • autenticação;
  • tratamento de erros;
  • timeout;
  • conversão de JSON;
  • classes de serviço;
  • organização do projeto;
  • exemplos práticos.

A ideia é que, ao final do artigo, você consiga utilizar esse conhecimento em aplicações reais.

1. O que é uma API REST?

REST significa Representational State Transfer.

Na prática, uma API REST permite que uma aplicação converse com outra aplicação através de requisições HTTP.

Imagine, por exemplo, que seu sistema Delphi precise consultar os dados de um cliente em um servidor.

O Delphi pode fazer uma requisição:

GET https://api.exemplo.com/clientes/10

O servidor processa a solicitação e devolve uma resposta, normalmente em JSON:

{
  "codigo": 10,
  "nome": "João da Silva",
  "email": "joao@exemplo.com"
}

O Delphi recebe esse JSON e transforma os dados em objetos, registros ou simplesmente acessa os campos diretamente.

A comunicação pode ser representada assim:

┌─────────────────┐
│ Aplicação Delphi│
└────────┬────────┘
         │
         │ HTTP/HTTPS
         ▼
┌─────────────────┐
│    API REST     │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Banco de dados  │
└─────────────────┘

2. O que é JSON?

JSON é um dos formatos mais utilizados para troca de informações entre aplicações.

JSON significa:

JavaScript Object Notation

Um objeto JSON pode ser:

{
  "codigo": 1,
  "nome": "Maria",
  "cidade": "Belém"
}

Também podemos receber uma lista:

[
  {
    "codigo": 1,
    "nome": "Maria"
  },
  {
    "codigo": 2,
    "nome": "João"
  }
]

No Delphi moderno, podemos trabalhar com JSON utilizando classes como:

TJSONObject
TJSONArray
TJSONValue

3. Métodos HTTP mais utilizados

As APIs REST normalmente utilizam os métodos HTTP para indicar a operação desejada.

Método Utilização
GET Consultar dados
POST Criar/enviar dados
PUT Atualizar dados
PATCH Atualização parcial
DELETE Excluir dados

Um CRUD de clientes poderia utilizar:

GET     /clientes
GET     /clientes/10
POST    /clientes
PUT     /clientes/10
DELETE  /clientes/10

4. O REST Client do Delphi

O Delphi possui componentes para trabalhar com REST.

Entre os principais estão:

TRESTClient
TRESTRequest
TRESTResponse

Uma arquitetura básica fica assim:

TRESTClient
     │
     ▼
TRESTRequest
     │
     ▼
TRESTResponse

O TRESTClient representa o cliente HTTP.

O TRESTRequest representa a requisição.

O TRESTResponse recebe a resposta da API.

5. Criando nosso primeiro projeto

Crie uma aplicação:

VCL Forms Application

No formulário, adicione:

TRESTClient
TRESTRequest
TRESTResponse
TButton
TMemo

Podemos utilizar os seguintes nomes:

RESTClient1
RESTRequest1
RESTResponse1
btnConsultar
Memo1

Configure:

RESTRequest1.Client = RESTClient1
RESTRequest1.Response = RESTResponse1

6. Units necessárias

Uma implementação básica poderá utilizar:

uses
  System.SysUtils,
  System.Classes,
  System.JSON,
  REST.Client,
  REST.Types,
  REST.Request,
  REST.Response.Adapter;

Dependendo da versão do Delphi e dos recursos utilizados, outras units podem ser necessárias.

7. Fazendo nossa primeira requisição GET

Vamos utilizar uma API pública de testes.

Por exemplo:

https://jsonplaceholder.typicode.com/posts/1

A ideia é solicitar o registro número 1.

Código:

procedure TForm1.btnConsultarClick(Sender: TObject);
begin
  RESTClient1.BaseURL :=
    'https://jsonplaceholder.typicode.com';

  RESTRequest1.Resource := 'posts/1';
  RESTRequest1.Method := rmGET;

  RESTRequest1.Execute;

  Memo1.Lines.Text :=
    RESTResponse1.Content;
end;

Se tudo estiver funcionando, o Memo deverá receber algo semelhante a:

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati",
  "body": "quia et suscipit..."
}

Parabéns.

Você acabou de consumir uma API REST usando Delphi.

8. Entendendo o código

Esta linha define a URL base:

RESTClient1.BaseURL :=
  'https://jsonplaceholder.typicode.com';

Depois informamos o recurso:

RESTRequest1.Resource := 'posts/1';

Juntando os dois:

https://jsonplaceholder.typicode.com/posts/1

Depois definimos o método:

RESTRequest1.Method := rmGET;

Finalmente:

RESTRequest1.Execute;

executa a requisição.

A resposta fica disponível em:

RESTResponse1.Content

9. Trabalhando com JSON

Em uma aplicação profissional, normalmente não queremos simplesmente jogar o JSON em um Memo.

Queremos interpretar os dados.

Podemos utilizar:

TJSONObject

Exemplo:

var
  JSON: TJSONObject;
begin

  RESTRequest1.Execute;

  JSON :=
    TJSONObject.ParseJSONValue(
      RESTResponse1.Content
    ) as TJSONObject;

  try

    if Assigned(JSON) then
    begin
      ShowMessage(
        JSON.GetValue<string>('title')
      );
    end;

  finally
    JSON.Free;
  end;

end;

Assim conseguimos acessar diretamente o campo:

"title"

10. Verificando se o JSON é válido

Não devemos assumir que toda resposta recebida será um JSON válido.

Uma API pode retornar:

  • JSON;
  • HTML;
  • mensagem de erro;
  • resposta vazia;
  • erro do servidor;
  • timeout.

Por isso, devemos verificar.

var
  JSONValue: TJSONValue;
begin

  JSONValue :=
    TJSONObject.ParseJSONValue(
      RESTResponse1.Content
    );

  try

    if not Assigned(JSONValue) then
      raise Exception.Create(
        'A API retornou um JSON inválido.'
      );

  finally
    JSONValue.Free;
  end;

end;

11. Verificando o HTTP Status Code

Outro ponto extremamente importante é verificar o status HTTP.

Alguns códigos comuns:

Código Significado
200 OK
201 Criado
204 Sem conteúdo
400 Requisição inválida
401 Não autenticado
403 Acesso proibido
404 Não encontrado
409 Conflito
422 Dados não processados
429 Muitas requisições
500 Erro interno
502 Bad Gateway
503 Serviço indisponível

Podemos verificar:

if RESTResponse1.StatusCode <> 200 then
begin
  raise Exception.Create(
    Format(
      'Erro HTTP %d: %s',
      [
        RESTResponse1.StatusCode,
        RESTResponse1.StatusText
      ]
    )
  );
end;

Uma API que retorna 404, por exemplo, não deve ser tratada como se tivesse retornado dados normalmente.

12. Criando uma função para GET

Em vez de repetir código em todos os formulários, podemos criar uma função:

function TForm1.ExecutarGET(
  const Recurso: string
): string;
begin

  RESTRequest1.Client := RESTClient1;
  RESTRequest1.Response := RESTResponse1;

  RESTRequest1.Resource := Recurso;
  RESTRequest1.Method := rmGET;

  RESTRequest1.Execute;

  if RESTResponse1.StatusCode < 200 then
    raise Exception.Create(
      'Erro na comunicação com a API.'
    );

  if RESTResponse1.StatusCode >= 300 then
    raise Exception.Create(
      Format(
        'Erro HTTP %d: %s',
        [
          RESTResponse1.StatusCode,
          RESTResponse1.StatusText
        ]
      )
    );

  Result := RESTResponse1.Content;

end;

Uso:

Memo1.Lines.Text :=
  ExecutarGET('posts/1');

13. GET com parâmetros

Imagine uma API:

GET /clientes?nome=Joao

Podemos adicionar parâmetros.

Uma forma de trabalhar com parâmetros é:

RESTRequest1.Params.AddItem(
  'nome',
  'Joao',
  pkGETorPOST
);

Depois:

RESTRequest1.Execute;

A API receberá algo semelhante a:

?nome=Joao

14. GET com vários parâmetros

Por exemplo:

/clientes?nome=Joao&cidade=Belem

Podemos fazer:

RESTRequest1.Params.Clear;

RESTRequest1.Params.AddItem(
  'nome',
  'Joao',
  pkGETorPOST
);

RESTRequest1.Params.AddItem(
  'cidade',
  'Belem',
  pkGETorPOST
);

Depois:

RESTRequest1.Execute;

15. Consumindo uma lista de registros

Agora imagine que a API retorne:

[
  {
    "codigo": 1,
    "nome": "João"
  },
  {
    "codigo": 2,
    "nome": "Maria"
  }
]

Nesse caso utilizamos:

TJSONArray

Exemplo:

var
  JSON: TJSONValue;
  ArrayJSON: TJSONArray;
  I: Integer;
begin

  RESTRequest1.Execute;

  JSON :=
    TJSONObject.ParseJSONValue(
      RESTResponse1.Content
    );

  try

    if not (JSON is TJSONArray) then
      raise Exception.Create(
        'A API não retornou uma lista.'
      );

    ArrayJSON := JSON as TJSONArray;

    for I := 0 to ArrayJSON.Count - 1 do
    begin
      Memo1.Lines.Add(
        ArrayJSON.Items[I]
          .GetValue<string>('nome')
      );
    end;

  finally
    JSON.Free;
  end;

end;

16. Consumindo POST

GET normalmente é utilizado para consulta.

Quando precisamos enviar dados para a API, geralmente utilizamos POST.

Imagine:

POST /clientes

Enviaremos:

{
  "nome": "João da Silva",
  "email": "joao@exemplo.com"
}

Podemos construir o JSON:

var
  JSON: TJSONObject;
begin

  JSON := TJSONObject.Create;

  try

    JSON.AddPair(
      'nome',
      'João da Silva'
    );

    JSON.AddPair(
      'email',
      'joao@exemplo.com'
    );

  finally
    JSON.Free;
  end;

end;

17. Enviando JSON para a API

Podemos utilizar um parâmetro de corpo.

Exemplo:

var
  JSON: TJSONObject;
begin

  JSON := TJSONObject.Create;

  try

    JSON.AddPair(
      'nome',
      'João da Silva'
    );

    JSON.AddPair(
      'email',
      'joao@exemplo.com'
    );

    RESTRequest1.Params.Clear;

    RESTRequest1.AddBody(
      JSON.ToJSON,
      ctAPPLICATION_JSON
    );

    RESTRequest1.Method := rmPOST;

    RESTRequest1.Resource :=
      'clientes';

    RESTRequest1.Execute;

  finally
    JSON.Free;
  end;

end;

O servidor receberá:

{
  "nome": "João da Silva",
  "email": "joao@exemplo.com"
}

18. POST com dados de um formulário

Imagine:

edtNome
edtEmail
edtTelefone

Podemos fazer:

JSON.AddPair(
  'nome',
  edtNome.Text
);

JSON.AddPair(
  'email',
  edtEmail.Text
);

JSON.AddPair(
  'telefone',
  edtTelefone.Text
);

Assim podemos transformar os dados da tela em JSON.

19. Utilizando PUT

PUT normalmente é utilizado para atualização.

Por exemplo:

PUT /clientes/10

JSON:

{
  "nome": "João da Silva",
  "email": "novoemail@exemplo.com"
}

No Delphi:

RESTRequest1.Resource :=
  'clientes/10';

RESTRequest1.Method := rmPUT;

RESTRequest1.Params.Clear;

RESTRequest1.AddBody(
  JSON.ToJSON,
  ctAPPLICATION_JSON
);

RESTRequest1.Execute;

20. Utilizando DELETE

Para excluir:

DELETE /clientes/10

No Delphi:

RESTRequest1.Resource :=
  'clientes/10';

RESTRequest1.Method := rmDELETE;

RESTRequest1.Execute;

Depois podemos verificar:

if RESTResponse1.StatusCode = 204 then
begin
  ShowMessage(
    'Cliente excluído com sucesso.'
  );
end;

O status retornado depende do contrato da API.

21. Headers HTTP

APIs frequentemente exigem headers.

Um dos mais comuns é:

Content-Type: application/json

Outro muito utilizado:

Accept: application/json

Podemos configurar:

RESTRequest1.Params.AddItem(
  'Content-Type',
  'application/json',
  pkHTTPHEADER
);

RESTRequest1.Params.AddItem(
  'Accept',
  'application/json',
  pkHTTPHEADER
);

22. Autenticação Bearer Token

Muitas APIs exigem autenticação.

Um padrão muito comum é:

Authorization: Bearer TOKEN

Exemplo:

RESTRequest1.Params.AddItem(
  'Authorization',
  'Bearer ' + Token,
  pkHTTPHEADER
);

Por exemplo:

Token :=
  'eyJhbGciOiJIUzI1NiIs...';

E:

RESTRequest1.Params.AddItem(
  'Authorization',
  'Bearer ' + Token,
  pkHTTPHEADER
);

23. Não deixe o token espalhado pelo código

Evite:

RESTRequest1.Params.AddItem(
  'Authorization',
  'Bearer 123456789',
  pkHTTPHEADER
);

Principalmente em sistemas comerciais.

O ideal é obter o token de uma configuração, processo de autenticação ou serviço específico.

Por exemplo:

Token := AuthService.Token;

E então:

RESTRequest1.Params.AddItem(
  'Authorization',
  'Bearer ' + Token,
  pkHTTPHEADER
);

24. API com login

Um fluxo bastante comum é:

Delphi
   │
   │ POST /login
   ▼
API
   │
   │ token
   ▼
Delphi
   │
   │ Authorization: Bearer TOKEN
   ▼
API

O Delphi envia:

{
  "usuario": "admin",
  "senha": "123456"
}

A API responde:

{
  "token": "abc123..."
}

Depois o Delphi utiliza:

Authorization: Bearer abc123...

nas próximas requisições.

25. Criando uma classe para API

Em projetos pequenos podemos utilizar os componentes diretamente nos formulários.

Em projetos profissionais, entretanto, é melhor criar uma camada específica.

Por exemplo:

Services
│
├── ApiClient.pas
├── AuthService.pas
├── ClienteService.pas
└── ProdutoService.pas

A ideia é:

Formulário
    │
    ▼
Service
    │
    ▼
ApiClient
    │
    ▼
REST API

Assim o formulário não precisa conhecer todos os detalhes de HTTP.

26. Classe ApiClient

Podemos começar com:

type
  TApiClient = class
  private
    FBaseURL: string;
    FToken: string;

  public
    constructor Create(
      const ABaseURL: string
    );

    function Get(
      const AResource: string
    ): string;

    function Post(
      const AResource: string;
      const ABody: string
    ): string;

    function Put(
      const AResource: string;
      const ABody: string
    ): string;

    function Delete(
      const AResource: string
    ): string;

    property Token: string read FToken write FToken;
  end;

Essa classe pode concentrar toda a comunicação.

27. Por que criar uma ApiClient?

Imagine um sistema com:

50 formulários

Se cada formulário implementar:

RESTClient
RESTRequest
RESTResponse

teremos muita duplicação.

Agora imagine centralizar:

BaseURL
Token
Headers
Timeout
Tratamento de erro
Logs
SSL
Status HTTP

em uma única classe.

A manutenção fica muito mais simples.

28. Tratamento profissional de exceções

Nunca é uma boa ideia fazer:

try
  RESTRequest1.Execute;
except
end;

Isso simplesmente ignora o problema.

Prefira:

try

  RESTRequest1.Execute;

  if RESTResponse1.StatusCode >= 400 then
    raise Exception.Create(
      Format(
        'API retornou HTTP %d: %s',
        [
          RESTResponse1.StatusCode,
          RESTResponse1.Content
        ]
      )
    );

except
  on E: Exception do
  begin
    // Registrar log
    raise;
  end;
end;

29. Diferencie erro de comunicação e erro HTTP

Essa distinção é importante.

Um erro pode ocorrer porque:

Servidor está fora do ar

ou porque:

Servidor respondeu 401

São situações diferentes.

Por exemplo:

Erro de comunicação
    ↓
Não conseguimos falar com a API

Erro HTTP 401
    ↓
Falamos com a API
    ↓
API recusou autenticação

Essa diferença deve ser tratada pelo sistema.

30. Timeout

Nunca deixe uma aplicação desktop ficar indefinidamente esperando uma API.

Configure timeout de acordo com a necessidade do projeto.

Os valores exatos dependem da versão e da camada HTTP utilizada, mas a ideia é estabelecer limites para:

  • conexão;
  • envio;
  • recebimento.

Em uma aplicação comercial, também é importante apresentar uma mensagem apropriada ao usuário:

Não foi possível comunicar com o servidor.
Verifique sua conexão com a Internet e tente novamente.

Em vez de simplesmente:

Socket Error #...

31. HTTPS

Ao consumir uma API na Internet, prefira:

https://

em vez de:

http://

Por exemplo:

https://api.meusistema.com

HTTPS protege a comunicação durante o transporte.

Isso é especialmente importante quando são transmitidos:

  • usuários;
  • senhas;
  • tokens;
  • dados financeiros;
  • informações pessoais;
  • documentos;
  • dados de clientes.

32. Não confie apenas no HTTPS

HTTPS protege o transporte, mas não resolve todos os problemas de segurança.

Também devemos considerar:

  • autenticação;
  • autorização;
  • expiração de tokens;
  • armazenamento de credenciais;
  • validação dos dados;
  • permissões;
  • logs;
  • proteção contra replay;
  • controle de acesso.

33. Serialização de objetos

Em projetos maiores, trabalhar diretamente com:

JSON.GetValue<string>('nome')

para dezenas de campos pode ficar trabalhoso.

Podemos criar classes.

Por exemplo:

type
  TCliente = class
  public
    Codigo: Integer;
    Nome: string;
    Email: string;
    Telefone: string;
  end;

E então criar uma camada de conversão JSON ↔ objeto.

Isso deixa o código muito mais organizado.

34. Criando um modelo de cliente

Por exemplo:

type
  TCliente = class
  private
    FCodigo: Integer;
    FNome: string;
    FEmail: string;
    FTelefone: string;

  public
    property Codigo: Integer
      read FCodigo write FCodigo;

    property Nome: string
      read FNome write FNome;

    property Email: string
      read FEmail write FEmail;

    property Telefone: string
      read FTelefone write FTelefone;
  end;

Agora temos um modelo de domínio.

35. Separando Model, Service e View

Uma arquitetura simples pode ser:

MODEL
   │
   ▼
SERVICE
   │
   ▼
API CLIENT
   │
   ▼
REST API

E a tela:

FORM
  │
  ▼
SERVICE

Por exemplo:

ClienteService.Listar;
ClienteService.Buscar(10);
ClienteService.Incluir(Cliente);
ClienteService.Alterar(Cliente);
ClienteService.Excluir(10);

Isso é muito mais fácil de manter do que espalhar requisições REST por dezenas de formulários.

36. Exemplo de ClienteService

Uma classe poderia ter:

type
  TClienteService = class
  private
    FApi: TApiClient;

  public
    constructor Create(
      AApi: TApiClient
    );

    function Listar: string;

    function Buscar(
      ACodigo: Integer
    ): string;

    function Inserir(
      const ACliente: TCliente
    ): string;

    function Alterar(
      const ACliente: TCliente
    ): string;

    procedure Excluir(
      ACodigo: Integer
    );
  end;

Assim o formulário fica extremamente simples.

37. Exemplo de uso no formulário

Em vez de:

RESTClient1.BaseURL := ...;
RESTRequest1.Resource := ...;
RESTRequest1.Params.Clear;
RESTRequest1.Execute;

o formulário pode fazer:

JSON := ClienteService.Listar;

Ou:

JSON := ClienteService.Buscar(10);

Essa é uma grande evolução arquitetural.

38. Paginação

APIs que retornam muitos registros normalmente utilizam paginação.

Por exemplo:

GET /clientes?page=1&limit=50

A API pode responder:

{
  "page": 1,
  "limit": 50,
  "total": 327,
  "data": [
    ...
  ]
}

No Delphi, podemos enviar:

RESTRequest1.Params.AddItem(
  'page',
  '1',
  pkGETorPOST
);

RESTRequest1.Params.AddItem(
  'limit',
  '50',
  pkGETorPOST
);

Em aplicações com muitos dados, paginação é fundamental para evitar respostas excessivamente grandes.

39. API retornando mensagens de erro

Uma API pode responder:

{
  "error": true,
  "message": "Cliente não encontrado."
}

Não devemos simplesmente mostrar o JSON inteiro ao usuário.

Podemos interpretar:

var
  JSON: TJSONObject;
  Mensagem: string;
begin

  JSON :=
    TJSONObject.ParseJSONValue(
      RESTResponse1.Content
    ) as TJSONObject;

  try

    if Assigned(JSON) then
    begin

      Mensagem :=
        JSON.GetValue<string>(
          'message',
          ''
        );

      if Mensagem <> '' then
        ShowMessage(Mensagem);

    end;

  finally
    JSON.Free;
  end;

end;

40. Logs

Uma aplicação profissional deve considerar logs.

Por exemplo:

2026-09-15 10:20:01
GET /clientes/10
HTTP 200
245 ms

Ou:

2026-09-15 10:21:35
POST /clientes
HTTP 500
Mensagem: Internal Server Error

O log pode ajudar muito na identificação de problemas.

Mas atenção:

Nunca registre tokens, senhas ou dados sensíveis sem uma justificativa e proteção adequada.

41. Retry

Nem todo erro significa que devemos tentar novamente.

Um erro:

401 Unauthorized

normalmente não deve simplesmente ser repetido.

Já um erro temporário:

503 Service Unavailable

pode, dependendo do contrato da API, permitir uma nova tentativa.

Em sistemas mais sofisticados podemos implementar:

Tentativa 1
   ↓
falhou
   ↓
aguarda
   ↓
Tentativa 2
   ↓
falhou
   ↓
aguarda
   ↓
Tentativa 3

O intervalo pode utilizar backoff.

É importante respeitar limites e orientações da própria API.

42. Rate Limit

Algumas APIs limitam o número de requisições.

Podemos receber:

HTTP 429

que indica excesso de requisições.

Se a API informar um tempo de espera, o cliente deve respeitar essa orientação.

Isso é particularmente importante em integrações com:

  • APIs de pagamento;
  • APIs de mensagens;
  • APIs de mapas;
  • serviços de terceiros;
  • serviços públicos;
  • APIs SaaS.

43. API REST em sistemas Delphi comerciais

Uma arquitetura muito interessante para sistemas comerciais é:

┌───────────────────────┐
│      Aplicação        │
│        Delphi         │
└───────────┬───────────┘
            │
          HTTPS
            │
            ▼
┌───────────────────────┐
│       API REST        │
│                       │
│ Autenticação          │
│ Regras de negócio     │
│ Validações            │
│ Permissões             │
└───────────┬───────────┘
            │
            ▼
┌───────────────────────┐
│       Banco SQL       │
└───────────────────────┘

Essa arquitetura pode ser muito interessante quando existem:

  • aplicativo desktop;
  • aplicativo Android;
  • aplicativo iOS;
  • painel web;
  • integrações externas.

Todos podem consumir a mesma API.

44. Delphi como cliente de uma API PHP

Um cenário muito comum é:

Delphi
   │
   ▼
API PHP
   │
   ▼
MySQL

O Delphi não acessa diretamente o MySQL.

Em vez disso:

Delphi
   │
   │ JSON
   ▼
PHP REST API
   │
   │ SQL
   ▼
MySQL

Essa arquitetura pode oferecer vantagens importantes de centralização das regras de negócio e controle de acesso.

45. Delphi + API + Flutter

Outra arquitetura interessante é:

                ┌──────────────┐
                │   Delphi     │
                │   Desktop    │
                └──────┬───────┘
                       │
                       │
                ┌──────▼───────┐
                │   API REST   │
                └──────┬───────┘
                       │
              ┌────────┴────────┐
              │                 │
        ┌─────▼─────┐     ┌─────▼─────┐
        │   MySQL   │     │ PostgreSQL│
        └───────────┘     └───────────┘
              ▲
              │
        ┌─────┴─────┐
        │   Flutter │
        │ Android/iOS│
        └───────────┘

Nesse modelo, Delphi e Flutter podem consumir a mesma API.

Isso é especialmente útil para sistemas que possuem desktop e aplicativo mobile.

46. Boas práticas

Ao desenvolver clientes REST em Delphi, procure seguir algumas regras.

1. Utilize HTTPS

Evite transmitir informações sensíveis por HTTP puro.

2. Não espalhe URLs

Centralize:

BaseURL

em uma configuração.

3. Centralize autenticação

O gerenciamento de token deve ficar em uma camada específica.

4. Utilize parâmetros

Não monte URLs manualmente com valores sem tratamento.

5. Valide o JSON

Não assuma que a resposta sempre terá o formato esperado.

6. Verifique o status HTTP

Um HTTP 400, 401 ou 500 precisa ser tratado adequadamente.

7. Utilize timeout

Evite deixar a interface congelada esperando indefinidamente.

8. Registre logs

Mas nunca exponha credenciais e tokens nos logs.

9. Separe responsabilidades

Utilize:

Form
Service
ApiClient
Model

10. Documente a API

Se você controla a API, mantenha documentação clara dos endpoints.

47. Estrutura profissional sugerida

Um projeto Delphi que consome várias APIs poderia ter:

MeuProjeto
│
├── Forms
│   ├── frmPrincipal.pas
│   ├── frmClientes.pas
│   └── frmProdutos.pas
│
├── Models
│   ├── uCliente.pas
│   └── uProduto.pas
│
├── Services
│   ├── uClienteService.pas
│   ├── uProdutoService.pas
│   └── uAuthService.pas
│
├── Infrastructure
│   ├── uApiClient.pas
│   ├── uApiConfig.pas
│   └── uApiException.pas
│
├── Utils
│
└── config.ini

Essa organização funciona muito bem para projetos que irão crescer.

48. Configurando a API através de INI

Assim como podemos utilizar INI para configurar banco de dados, também podemos configurar a API.

Exemplo:

[API]
BaseURL=https://api.meusistema.com
Timeout=30000
Version=v1

No Delphi:

Ini.ReadString(
  'API',
  'BaseURL',
  ''
);

Isso permite mudar o endereço da API sem recompilar o aplicativo.

49. Ambiente de desenvolvimento e produção

Podemos utilizar:

[API]
BaseURL=https://api-dev.meusistema.com

durante o desenvolvimento.

E:

[API]
BaseURL=https://api.meusistema.com

em produção.

O executável pode ser o mesmo.

Somente a configuração muda.

Essa abordagem reduz a necessidade de recompilar o sistema para cada ambiente.

50. Cuidado com credenciais no INI

Embora o INI seja muito útil para configurações, não devemos tratar um arquivo INI comum como um cofre de segredos.

Evite armazenar:

Password=senha_super_secreta
Token=token_completo

sem avaliar o risco.

Dependendo do tipo de aplicação, considere:

  • armazenamento seguro do sistema operacional;
  • credenciais temporárias;
  • tokens com expiração;
  • autenticação apropriada;
  • criptografia;
  • servidor intermediário;
  • permissões adequadas.

51. Uma API REST não é apenas HTTP + JSON

É importante entender que uma integração profissional depende de um contrato.

Esse contrato precisa definir:

Endpoint
Método HTTP
Headers
Autenticação
Parâmetros
Formato da requisição
Formato da resposta
Status HTTP
Mensagens de erro
Paginação
Limites
Versionamento

Por exemplo:

POST /api/v1/clientes

Request:

{
  "nome": "João",
  "email": "joao@email.com"
}

Response:

{
  "codigo": 15,
  "nome": "João",
  "email": "joao@email.com"
}

Status:

201 Created

Isso é muito melhor do que simplesmente "fazer um POST".

52. Versionamento de API

Em projetos profissionais, é comum versionar APIs.

Por exemplo:

/api/v1/clientes

e posteriormente:

/api/v2/clientes

Isso permite evoluir a API sem necessariamente quebrar aplicações antigas.

Para aplicações Delphi distribuídas para muitos clientes, isso pode ser particularmente importante.

53. Checklist para uma integração REST

Antes de colocar uma integração em produção, verifique:

☐ URL configurada
☐ HTTPS
☐ Método HTTP correto
☐ Headers
☐ Content-Type
☐ Accept
☐ Autenticação
☐ Token
☐ Timeout
☐ Tratamento de erros
☐ Status HTTP
☐ JSON validado
☐ Logs
☐ Retry quando apropriado
☐ Rate limit
☐ Versionamento
☐ Configuração de produção
☐ Segurança das credenciais

54. Exemplo de fluxo completo

Um fluxo profissional pode ser:

Usuário
   │
   ▼
Formulário Delphi
   │
   ▼
ClienteService
   │
   ▼
ApiClient
   │
   ├── URL
   ├── Headers
   ├── Token
   ├── Timeout
   └── HTTP
   │
   ▼
API REST
   │
   ▼
JSON
   │
   ▼
ApiClient
   │
   ▼
Service
   │
   ▼
Model
   │
   ▼
Formulário

Essa separação proporciona uma arquitetura muito mais organizada.

55. Exemplo de implementação simplificada

Um cliente REST básico pode seguir este conceito:

procedure TApiClient.ConfigurarRequest(
  ARequest: TRESTRequest
);
begin

  ARequest.Params.Clear;

  ARequest.Params.AddItem(
    'Accept',
    'application/json',
    pkHTTPHEADER
  );

  ARequest.Params.AddItem(
    'Content-Type',
    'application/json',
    pkHTTPHEADER
  );

  if FToken <> '' then
  begin
    ARequest.Params.AddItem(
      'Authorization',
      'Bearer ' + FToken,
      pkHTTPHEADER
    );
  end;

end;

Agora todos os requests podem passar pela mesma configuração.

56. Consumindo APIs reais

Depois de entender os exemplos, você poderá utilizar a mesma estrutura para consumir APIs de:

  • pagamentos;
  • mapas;
  • CEP;
  • emissão fiscal;
  • WhatsApp;
  • bancos;
  • e-commerce;
  • transportadoras;
  • serviços governamentais;
  • sistemas internos;
  • ERPs;
  • CRMs;
  • plataformas SaaS.

O princípio é sempre semelhante:

Request
   ↓
HTTP
   ↓
API
   ↓
Response
   ↓
JSON
   ↓
Delphi

O que muda é o contrato específico de cada API.

57. Conclusão

Consumir uma API REST no Delphi não precisa ser complicado.

Com os componentes:

TRESTClient
TRESTRequest
TRESTResponse

podemos realizar requisições HTTP e trabalhar com serviços externos de maneira bastante prática.

Entretanto, em aplicações profissionais, o mais importante não é apenas conseguir executar:

RESTRequest1.Execute;

É criar uma estrutura que seja:

  • organizada;
  • segura;
  • reutilizável;
  • testável;
  • fácil de manter;
  • preparada para crescer.

Para projetos pequenos, os componentes REST podem ser utilizados diretamente.

Para projetos maiores, uma arquitetura baseada em:

Form
  ↓
Service
  ↓
ApiClient
  ↓
REST API

é uma abordagem muito mais interessante.

Quando combinamos essa arquitetura com:

Delphi
+
REST API
+
JSON
+
HTTPS
+
Autenticação
+
MySQL/PostgreSQL

podemos construir aplicações modernas capazes de conversar com praticamente qualquer serviço que disponibilize uma API HTTP.

Perguntas frequentes

O Delphi consegue consumir API REST?

Sim. O Delphi possui componentes REST próprios, como TRESTClient, TRESTRequest e TRESTResponse, além de outras alternativas disponíveis no ecossistema.

Preciso instalar um componente externo para consumir REST?

Não necessariamente. Para muitas integrações, os recursos REST disponíveis no próprio Delphi são suficientes.

Delphi consegue trabalhar com JSON?

Sim. O Delphi possui classes para trabalhar diretamente com JSON, incluindo TJSONObject e TJSONArray.

Posso consumir uma API PHP usando Delphi?

Sim. Desde que a aplicação PHP disponibilize uma API HTTP, o Delphi pode consumi-la através de requisições REST.

Posso utilizar Bearer Token?

Sim. Um dos padrões mais comuns é enviar o token no header:

Authorization: Bearer TOKEN

Posso consumir API REST em aplicativo Android desenvolvido com Delphi?

Sim. A arquitetura precisa considerar as particularidades da plataforma, permissões, HTTPS, certificados e biblioteca HTTP utilizada.

É possível utilizar Delphi com uma API e MySQL?

Sim. Uma arquitetura comum é:

Delphi → API REST → MySQL

Nesse modelo, a aplicação Delphi não precisa acessar diretamente o banco de dados.

É melhor acessar MySQL diretamente ou através de API?

Depende da arquitetura do sistema. Uma API pode ser interessante quando existem múltiplos clientes, como desktop, mobile e web, porque centraliza regras de negócio, autenticação e acesso ao banco.

Posso colocar a URL da API diretamente no código?

Pode, mas para aplicações que possuem diferentes ambientes ou precisam de manutenção frequente, é melhor centralizar a configuração, por exemplo, em um arquivo INI ou outro mecanismo de configuração adequado.

Como tratar erros da API?

Verifique tanto os erros de comunicação quanto o código HTTP retornado e, quando disponível, interprete a estrutura de erro definida pelo contrato da API.

Resumo

Se você precisa lembrar apenas do essencial:

TRESTClient
      +
TRESTRequest
      +
TRESTResponse
      ↓
    HTTP
      ↓
   REST API
      ↓
    JSON

E, para projetos maiores:

Form
 ↓
Service
 ↓
ApiClient
 ↓
REST API
 ↓
JSON
 ↓
Model
 ↓
Form

Essa separação é um excelente ponto de partida para construir integrações REST profissionais em Delphi.


← Mais Novos Mais Antigos →