DEV Community: Ezequiel Otoni

Stored Procedures na prática: implementando regras de negócio com PL/SQL

Ezequiel Otoni — Sat, 17 Oct 2026 02:55:27 +0000

Que é possível criar métodos e funções para manipular um banco de dados no back-end, isso você já sabe. Mas e se eu te contar que também é possível criar lógica e armazená-la dentro do próprio banco melhorando nossas aplicações? Stored Procedures (procedimentos armazenados) são uma arma poderosa no desenvolvimento de sistemas que usam banco de dados. Neste artigo, vamos entender o que são procedures, quais as vantagens de usá-las e como funcionam na prática, com um exemplo de transferência bancária em PL/SQL (Oracle). No final, veremos como chamá-las a partir de uma aplicação Spring Boot. Boa leitura!

Sumário

O que é uma Procedure?
Qual a vantagem de usar Procedures?
Estrutura e sintaxe explicada
Conectando com o Back-End
Conclusão

O que é uma Procedure?

Uma procedure é um bloco de código que armazenamos no banco de dados e que pode ser chamado pelo nome quantas vezes for preciso. Ela pode receber parâmetros, executar comandos SQL e lógica procedural. Por isso, é muito usada para encapsular regras de negócio complexas, tarefas repetitivas e lógicas que são compartilhadas em vários contextos. Cada procedure criada tem uma tarefa específica geralmente descrita no seu nome, assim como em um método.

Vamos aprender usando o exemplo da procedure transferir(), que vai realizar uma transferência bancária. Para fins de esclarecimento, vale lembrar que cada SGBD implementa esse conceito com sua própria sintaxe, e neste artigo usaremos o PL/SQL, a extensão procedural da Oracle para o SQL.

Qual a vantagem de usar Procedures?

Agora que já sabemos o que é uma procedure, fica a pergunta: qual a real vantagem de ter esse trabalho todo?

A boa notícia é que, com esse código armazenado, nosso sistema ganha em vários aspectos:

Diminuição do tráfego na rede, pois são menos idas e vindas entre a aplicação e o banco;
Reusabilidade de código, já que uma vez criado ele pode ser usado em diversos componentes e até por aplicações diferentes, independente do back-end;
Consistência, porque regras críticas (como debitar, creditar e registrar uma transferência) ficam junto dos dados e seguem sempre o mesmo caminho;
Mais segurança, uma vez que a lógica fica abstraída no banco sendo acessada via procedure sem dar à aplicação o acesso direto às tabelas.

Algumas dessas vantagens, como a redução do tráfego, também podem melhorar a performance da aplicação. Contudo, é válido lembrar que as procedures também têm pontos negativos:

Maior dependência do banco escolhido, o que dificulta a migração;
Maior dificuldade para testes, visto que testar dentro do banco não é tão trivial;
Lógica dividida entre banco e aplicação, o que exige organização para não se perder, sobretudo com muitas procedures.

Estrutura e sintaxe explicada

Agora vamos entender como criar uma procedure e, como dito antes, usaremos a sintaxe PL/SQL. Neste exemplo vamos criar a procedure transferir() que realiza uma transferência bancária. Aqui temos um primeiro esqueleto:

CREATE OR REPLACE PROCEDURE transferir()
IS
BEGIN
    -- Lógica aqui
END;
/

CREATE OR REPLACE PROCEDURE: instrui o banco a criar a procedure ou, se ela já existir, substituí-la;
transferir(): é o nome da procedure que se assemelha muito ao nome de um método/função. E da mesma forma, é aqui que vamos receber os parâmetros;
IS: palavra-chave que marca o fim do cabeçalho e início da seção de declarações. Aqui vamos declarar as variáveis;
BEGIN/END: entre esses comandos colocamos toda a lógica da procedure (validações, condições) e a manipulação do banco (inserts, selects). O END sempre termina com ponto e vírgula;
/: sinaliza ao cliente que o bloco terminou, mas não faz parte da procedure. Em outros SGBDs existem outras formas de delimitação.

O próximo passo é adicionar lógica à nossa procedure. Para isso precisamos de parâmetros e também variáveis. Veja:

CREATE OR REPLACE PROCEDURE transferir (
    p_valor            IN NUMBER,
    p_conta_origem_id  IN NUMBER,
    p_conta_destino_id IN NUMBER
)
IS
    v_saldo_origem NUMBER;
    v_saldo_destino NUMBER;
BEGIN
    SELECT saldo INTO v_saldo_origem
      FROM contas
     WHERE id = p_conta_origem_id;

    -- Garante que a conta de destino existe
    SELECT saldo INTO v_saldo_destino
      FROM contas
     WHERE id = p_conta_destino_id;

    UPDATE contas SET saldo = saldo - p_valor WHERE id = p_conta_origem_id;
    UPDATE contas SET saldo = saldo + p_valor WHERE id = p_conta_destino_id;

    INSERT INTO transacoes (valor, conta_origem_id, conta_destino_id)
    VALUES (p_valor, p_conta_origem_id, p_conta_destino_id);
END;
/

Vamos ver o que fizemos até aqui:

IN / OUT / IN OUT: o modo do parâmetro. IN é entrada (a procedure lê o valor e não pode alterá-lo); OUT é saída (a procedure atribui um valor que volta para quem chamou); IN OUT entra com um valor e pode devolvê-lo modificado. Todos os nossos parâmetros são IN;
p_valor IN NUMBER: nome, modo e tipo do parâmetro. Neste caso o valor é numérico e vale dizer que cada SGBD aceita tipos específicos;
v_saldo_origem NUMBER: variável que recebe o saldo da conta de origem no SELECT;
v_saldo_destino NUMBER: variável que recebe o saldo da conta de destino. Aqui só a usamos para confirmar que a conta existe.

O restante é um código SQL simples com SELECT (leitura dos saldos), UPDATE (débito e crédito nas contas origem e destino), e o INSERT (registro da transferência). Mas perceba que nosso código ainda não valida nada: se o saldo for insuficiente, a conta ficaria negativa, e se o valor for negativo, a transferência andaria no sentido contrário. Por enquanto, ele não é seguro.

Então vamos adicionar validações e lançar mensagens de erro!

CREATE OR REPLACE PROCEDURE transferir (
    p_valor            IN NUMBER,
    p_conta_origem_id  IN NUMBER,
    p_conta_destino_id IN NUMBER
) IS
    v_saldo_origem  NUMBER;
    v_saldo_destino NUMBER;
BEGIN
    IF p_conta_origem_id = p_conta_destino_id THEN
        RAISE_APPLICATION_ERROR(-20001, 'Os números precisam ser de contas diferentes!');
    END IF;

    IF p_valor <= 0 THEN
        RAISE_APPLICATION_ERROR(-20002, 'O valor de transferência precisa ser maior que 0!');
    END IF;

    -- O FOR UPDATE trava a conta de origem e lê o saldo
    SELECT saldo INTO v_saldo_origem
      FROM contas
     WHERE id = p_conta_origem_id
       FOR UPDATE;

    -- Confirma que a conta de destino existe (senão, cai no NO_DATA_FOUND)
    SELECT saldo INTO v_saldo_destino
      FROM contas
     WHERE id = p_conta_destino_id;

    IF v_saldo_origem >= p_valor THEN
        UPDATE contas SET saldo = saldo - p_valor WHERE id = p_conta_origem_id;
        UPDATE contas SET saldo = saldo + p_valor WHERE id = p_conta_destino_id;

        INSERT INTO transacoes (valor, conta_origem_id, conta_destino_id)
        VALUES (p_valor, p_conta_origem_id, p_conta_destino_id);
    ELSE
        RAISE_APPLICATION_ERROR(-20003, 'O saldo disponível é insuficiente!');
    END IF;

    EXCEPTION
      WHEN NO_DATA_FOUND THEN
        RAISE_APPLICATION_ERROR(-20004, 'Conta não encontrada');
END;
/

Agora sim estamos validando todos os cenários e lançando erros:

Se as contas de destino e origem forem iguais;
Se o valor a ser transferido for menor ou igual a zero;
Se o saldo da conta de origem for insuficiente para a transferência;
Se uma ou as duas contas não existirem.

Para isso, RAISE_APPLICATION_ERROR lança um erro personalizado, com código entre -20000 e -20999 e uma mensagem. NO_DATA_FOUND é uma exceção do próprio Oracle, disparada quando um SELECT ... INTO não encontra nenhuma linha. Nós a tratamos na seção EXCEPTION.

O FOR UPDATE trava a linha da conta de origem até o fim da transação. Sem ele, duas transferências simultâneas poderiam ler o mesmo saldo e gastar o mesmo dinheiro duas vezes.

Agora uma parte importante. Nosso código não faz commit, ou seja, as alterações não são definitivas. Isso é proposital, pois deixamos a parte de confirmar a transação para quem chama a procedure. Por isso, depois de chamar a procedure, rode COMMIT; para tornar as alterações definitivas (ou ROLLBACK; para desfazê-las).

Para testar até aqui, você precisa de um SGBD (neste caso, o Oracle) e de um cliente de banco de dados, como o DBeaver, que serve como interface para enviar os comandos ao banco. Mas antes, é necessário criar as tabelas clientes, contas e transacoes, essa última para registrarmos as transferências, exatamente nessa ordem, por causa das chaves estrangeiras. Além disso, é preciso inserir clientes e contas para a transferência ter com o que trabalhar.

Tabela clientes

CREATE TABLE clientes (
    id NUMBER GENERATED ALWAYS AS IDENTITY,
    nome VARCHAR2(100) NOT NULL,
    email VARCHAR2(150) NOT NULL UNIQUE,
    cpf VARCHAR2(11) NOT NULL UNIQUE,
    CONSTRAINT clientes_pk PRIMARY KEY (id)
);

Tabela contas

CREATE TABLE contas (
    id NUMBER GENERATED ALWAYS AS IDENTITY,
    cliente_id NUMBER NOT NULL,
    numero VARCHAR2(100) NOT NULL UNIQUE,
    saldo NUMBER(15,2) DEFAULT 0 NOT NULL,
    CONSTRAINT contas_pk PRIMARY KEY (id),
    CONSTRAINT fk_contas_cliente FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);

Tabela transacoes

CREATE TABLE transacoes (
    id NUMBER GENERATED ALWAYS AS IDENTITY,
    valor NUMBER(15,2) NOT NULL,
    conta_origem_id NUMBER NOT NULL,
    conta_destino_id NUMBER NOT NULL,
    data_transacao TIMESTAMP DEFAULT SYSTIMESTAMP NOT NULL,
    CONSTRAINT transacoes_pk PRIMARY KEY (id),
    CONSTRAINT fk_transacoes_conta_origem FOREIGN KEY (conta_origem_id) REFERENCES contas(id),
    CONSTRAINT fk_transacoes_conta_destino FOREIGN KEY (conta_destino_id) REFERENCES contas(id)
);

Dados de exemplo

INSERT INTO clientes (nome, email, cpf) VALUES ('Maria Silva', 'maria@email.com', '11111111111');
INSERT INTO clientes (nome, email, cpf) VALUES ('João Souza', 'joao@email.com', '22222222222');

INSERT INTO contas (cliente_id, numero, saldo) VALUES (1, '0001-1', 1000);
INSERT INTO contas (cliente_id, numero, saldo) VALUES (2, '0002-2', 1000);

COMMIT;

Com as contas criadas, basta chamar a procedure e fazer o commit. Exemplo simples usando DBeaver:

-- transferir(valor, id da conta de origem, id da conta de destino)
CALL transferir(100, 2, 1);
COMMIT;

SELECT id, saldo FROM contas;

Lembra que a procedure não executa COMMIT? É por isso que ele aparece aqui: quem chama decide quando confirmar. Com isso, a procedure está funcionando, mas nosso trabalho não para por aqui. A seguir vamos ver como seria fazer essa chamada via back-end.

Conectando com o Back-End

Neste exemplo vamos utilizar o Spring Boot com Spring JDBC + JdbcTemplate para executar a procedure, mas a vantagem de utilizar procedures é que qualquer back-end pode chamá-las.

O JDBC é uma API Java que permite a interação com bancos relacionais e o JdbcTemplate é uma classe auxiliar do Spring que trabalha sobre o JDBC facilitando nossa vida.

Em uma classe service injetamos o JdbcTemplate, e usamos o método update passando a chamada da procedure:

  private final JdbcTemplate jdbcTemplate;

  public TransacaoService(JdbcTemplate jdbcTemplate) {
      this.jdbcTemplate = jdbcTemplate;
  }

Agora o método:

@Transactional
public String transferir(TransferenciaDto data) {
    String query = "{CALL transferir(?,?,?)}";

    jdbcTemplate.update(
        query,
        data.valor(),
        data.contaOrigemId(),
        data.contaDestinoId()
    );

    return "Transferência realizada com sucesso!";
}

Vamos destrinchar o que criamos aqui:

Usamos a anotação @Transactional, dado que nossa procedure não faz commit nem rollback. Com ela, o Spring confirma a transação ou cancela se uma exceção for lançada (como os erros da procedure);
A query é a sintaxe da chamada da procedure passando interrogações no lugar de cada parâmetro;
O método update executa a chamada no banco. Os valores passados em seguida substituem os ? na ordem em que aparecem.

Se tudo der certo, o método retorna a mensagem de sucesso que definimos. Se a procedure lançar um erro, o método é interrompido e um handler devolve ao cliente a mensagem de erro que veio da procedure.

Veja um exemplo simples, usando o @ExceptionHandler do Spring para capturar o erro e uma regex para extrair a mensagem de cada situação:

@ExceptionHandler(UncategorizedSQLException.class)
public ResponseEntity<String> handleProcedureError(UncategorizedSQLException ex) {
    String fullMessage = ex.getCause().getMessage();

    Pattern pattern = Pattern.compile("ORA-\\d+: ([^\n]+)");
    Matcher matcher = pattern.matcher(fullMessage);

    String cleanMessage = matcher.find() ? matcher.group(1).trim() : "Erro ao processar a transferência";

    return ResponseEntity.badRequest().body(cleanMessage);
}

Aqui capturamos a UncategorizedSQLException, que é o que o Spring lança para erros do banco que ele não reconhece, como os definidos com RAISE_APPLICATION_ERROR. É uma simplificação proposital para pegar as mensagens da procedure.

Dessa forma, saberemos se a transferência foi concluída com sucesso, ou se caímos em algum dos erros de validação mapeados no capítulo 3.

Conclusão

Assim, concluímos este artigo entendendo um pouco mais sobre como as procedures são um recurso poderoso no desenvolvimento de sistemas. Se usadas corretamente, podem melhorar muito uma aplicação, mas requerem cautela e uma análise cuidadosa de arquitetura. Vimos aqui apenas uma introdução ao tema, já que este é um assunto complexo em que vale a pena mergulhar um pouco mais. No próximo artigo desta série, veremos as functions, outro recurso muito interessante do banco de dados.

Se quiser ver esse projeto completo, clique aqui: repositório

Iniciando no Angular: Dicas e estrutura inicial

Ezequiel Otoni — Thu, 22 Aug 2024 14:51:01 +0000

Se você é um Dev Front-End iniciante que está querendo vir pro lado Angular da força, já está de parabéns só pela decisão acertada. Esse artigo é o primeiro de uma série que tem o intuito de entender e espalhar a palavra desse framework tão amado na comunidade. Boa leitura!

Sumário

Por que Angular?
Iniciando um projeto
Estrutura inicial
Entendendo a inicialização

Por que usar Angular?

Bom, porque ele é melhor. E pronto!

Na verdade, o Angular é um framework robusto que adota uma arquitetura baseada em componentes reutilizáveis e escaláveis, utiliza o TypeScript que é uma linguagem com tipagem estática, possui tudo o que é necessário para o desenvolvimento web como roteamento, validação de formulários, comunicação http e gerenciamento de estado. Sem falar do sistema modular, injeção de dependências e a CLI (interface de linha de comando) integrada que facilita muito no desenvolvimento das aplicações. Já ficou óbvio que ele é o melhor.

Mas vamos entender melhor sua estrutura.

Iniciando o projeto

O primeiro passo é instalar a CLI do Angular na nossa máquina. No terminal você pode digitar o comando:

 npm install -g @angular/cli

Aqui estamos instalando globalmente a versão mais recente da CLI. Após isso pelo terminal escolha um diretório para criar o projeto usando o comando padrão do Angular:

 ng new 'nome do projeto'

O projeto vai começar a ser criado e nesse processo você terá que escolher o formato de estilo que será usado (CSS, SCSS, SASS, LESS) e se o projeto vai usar um sistema de roteamento. No estilo você pode escolher o que mais gosta de utilizar, mas sobre o roteamento, falaremos melhor em outros artigos. Ao final seu projeto vai ser criado com as configurações escolhidas e na versão da CLI instalada.

Mas e se você não quiser instalar a CLI globalmente e nem quiser uma versão fixa do Angular na sua máquina? Nesse caso podemos usar um atalho:

npx -p @angular/cli@16 ng new jornada-coders --style=scss --routing=true

Esse comando significa:

npx: O npx é um executor de pacotes do npm que, me permite nesse caso, criar o projeto com uma versão do Angular que não tenho instalada localmente.
-p @angular/cli@16: Indica o pacote Angular CLI e a versão que vamos utilizar. Nesse caso escolhi a versão 16 mas poderia ser outra por exemplo @angular/cli@13.2.0;
ng new jornada-coders: Esse comando já é conhecido dos devs Angular pois é a forma padrão de iniciar um projeto. Estamos dizendo para criar um novo projeto e o nome dele.
--style=scss: aqui já estou escolhendo que meu projeto vai usar scss que é o que uso normalmente. Se você não colocar nada vai poder escolher antes de o projeto ser criado.
--routing=false: Aqui é similar pois já estou indicando que meu projeto não vai ser criado com um modulo de rotas. Caso você também não coloque essa parte, vai poder que escolher antes do projeto ser criado.

Após isso você terá algo assim:

Um projeto inicial Angular padrão. Entrando na pasta do projeto pelo terminal temos acesso à CLI integrada e digitando o comando ng serve , nossa aplicação será iniciada no endereço padrão do Angular http://localhost:4200/. Abrindo esse link teremos nossa aplicação rodando localmente:

Estrutura inicial

Um projeto Angular é criado com muitos arquivos e pastas mas é uma estrutura fácil de compreender. Vamos ver os principais que são:

src/: É o diretório principal onde o código da aplicação vai ficar.
- app/: É o componente inicial da aplicação e vai conter os demais componentes, módulos e serviços criados. Ele é criado com o padrão do Angular que é um arquivo .html, um de estilo .scss, um de script .ts, um de teste .spec.ts e um módulo.
- app.module.ts: Esse é o módulo raiz que declara e importa os componentes e outros módulos que serão criados na aplicação.
- assets/: Pasta para armazenar imagens e outros recursos.
- styles.scss: É o arquivo raiz de estilos da aplicação.
- index.html: É o arquivo HTML raiz da aplicação. É ele que será exibido no navegador.
- main.ts: Arquivo raiz de script da aplicação. É ele que vai iniciar o projeto.
angular.json: Esse é o arquivo de configuração que define como a CLI deve construir e compilar o projeto. Contém as informações principais da aplicação.
package.json: Lista as dependências e scripts do projeto.
tsconfig.json: É um arquivo de configuração do TypeScript, que contém as configurações do compilador.

Entendendo a inicialização

Agora que entendemos os principais arquivos vamos entender como o Angular inicializa a aplicação. Vamos apagar tudo no arquivo app.component.html e vamos colocar o clássico <h1>Hello World!</h1>. Ao subir a aplicação novamente podemos ver a mudança.

Mas se temos um arquivo index.html que é a entrada da aplicação, por que o que colocamos no app.component é que aparece no navegador? Na verdade o que está acontecendo é:

1- Primeiro o Angular encontra o arquivo index.html, que contém no <body>, apenas um seletor que é o <app-root></app-root>. É nesse seletor que vai ser injetado o conteúdo principal da aplicação.

</h1>`. Ao subir a aplicação novamente podemos ver 
    <meta charset="utf-8" />
    <title>JornadaCoders</title>
    <base href="/" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="icon" type="image/x-icon" href="favicon.ico" />
  </head>
  <body>
    <app-root></app-root>
  </body>
</html>

2 - O Angular define qual é o componente inicial da aplicação através da propriedade bootstrap no app.module.ts. Vamos entender esse módulo:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

Um módulo é uma classe TypeScript decorada com a anotação NgModule. Nela agrupamos componentes, services, diretivas deixando tudo organizado e modularizado, pois em cada módulo, precisamos configurar apenas o que é preciso naquela parte da aplicação. Aqui vemos o módulo raiz então ele vai lidar com as configurações globais da aplicação como inicialização e importação de outros módulos que ficarão disponíveis globalmente. Ele possui algumas propriedades que são:

declarations:
- Aqui declaramos componentes, diretivas ou serviços desse mesmo módulo. Nesse caso o AppComponent.
imports:
- Aqui listamos os módulos que estamos importando, podendo assim usar seus componentes ou diretivas no nosso. Nesse caso só estamos importando o BrowserModule que é um módulo necessário para que nossa aplicação funcione em navegadores. Ele só precisa ser importado nesse módulo raiz.
providers:
- Aqui colocamos os serviços que serão fornecidos pelo módulo. Esses serviços ficarão disponíveis para injeção de dependência em todo o módulo e nos módulos que o importam. Nesse caso não temos nada então podemos deixar vazio.
bootstrap:
- E por fim, aqui colocamos os componentes que são carregados ao iniciar a aplicação. Devemos colocar essa propriedade apenas no módulo raiz. E essa é a propriedade responsável por injetar algo no seletor <app-root> do arquivo index.html. Nela estamos dizendo que o componente a ser carregado ao iniciar a aplicação é o AppComponent. Sendo assim o Angular vai injetar esse componente no <app-root>, e o que colocarmos no AppComponent vai ser mostrado no navegador.

E é assim que o Angular funciona. Ele parte do módulo principal para iniciar a aplicação e a partir dele, podemos criar outros módulos, páginas, componentes, serviços. Tudo vai sempre seguir essa estrutura modularizada e organizada tornando a construção e a manutenção de uma aplicação fácil, eficiente e concisa. Espero ter conseguido mostrar como é simples esse início e atiçado sua curiosidade. Te aguardo nos próximos artigos!

Como fazer Deploy de uma api com Json-Server

Ezequiel Otoni — Sun, 15 Oct 2023 21:05:55 +0000

Todo dev Front-End iniciante já ficou perdido na hora de fazer deploy de um projeto que dependia de uma fake api com Json-Server. Localmente é uma maravilha. Mas, e na hora de enviar pra um amigo, postar seu projeto no grupo da familia ou portfólio? Bom, nesse artigo, trago duas formas de fazer o deploy da sua api bem rápido e simples.

Sumário

Criando a Database
Configurando o Json-Server
Subindo a aplicação no Github
Deploy no Glitch
Deploy na Vercel

Criando a Database

Primeiro vamos criar uma pasta para iniciar nosso projeto. No seu editor de código favorito abra a pasta e crie um arquivo com o nome db.json que será sua database. Nesse arquivo cole ou crie seu arquivo json.

{
  "produtos": [
    {
      "nome": "Óculos de sol",
      "preco": "120,00",
      "id": 1
    },
    {
      "nome": "Calça",
      "preco": "60,00",
      "id": 2
    },
    {
      "nome": "Boné adidas",
      "preco": "85,00",
      "id": 3
    },
    {
      "nome": "Relógio",
      "preco": "350,00",
      "id": 4
    },
    {
      "nome": "Jaqueta",
      "preco": "90,00",
      "id": 5
    }
  ]
}

Agora nossa pasta está assim e o próximo passo é configurar o json-server.

Configurando o Json-Server

Primeiro vamos acessar o terminal e, dentro da pasta do projeto, dar o comando npm init -y para criarmos o arquivo package.json que terá todas as configurações. Ainda no terminal vamos instalar o Json-Server com o comando npm install json-server. Após a instalação serão gerados automaticamente um arquivo package-lock.json e a pasta node_modules. Para finalizar vamos criar, na raiz do projeto, o arquivo server.js e adicionar nele as configurações de conexão com o Json-Server.

const jsonServer = require('json-server');
const server = jsonServer.create();
const router = jsonServer.router('db.json');
const middlewares = jsonServer.defaults();

server.use(middlewares);
server.use(router);
server.listen(3000, () => {
  console.log('JSON Server is running')
});

Nos scripts do package.json, vamos adicionar a linha "start": "node server.js" que contém o comando pra iniciar a aplicação.

Se você fez tudo correto até aqui, sua pasta deve estar assim:

E assim seu arquivo package.json:

{
  "name": "exemplo-api",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node server.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "json-server": "^0.17.4"
  }
}

Caso queira, você pode editar o nome e adicionar uma descrição. Note que o json-server já aparece como dependência do projeto e o comando start já está na lista de scripts.
Para conferir se deu certo, no terminal digite o comando npm start e, se funcionar, teremos essa mensagem no console:

Ao acessar o endereço http://localhost:3000 já podemos ver a página de sucesso do json-server. E ao acessar o endpoint http://localhost:3000/produtos já é possível fazer um CRUD localmente.

Subindo a aplicação no Github

Agora vamos criar um repositório no github para o nosso projeto, fazer os commits e subir a aplicação. Mas antes, crie um arquivo .gitignore e adicione nele a pasta node_modules pois não é necessessário subir ela. Assim deve ficar o seu repositório.

Mais informações aqui.

Deploy no Glitch

O Glitch é uma plataforma gratuita para hospedagem de páginas e aplicações web. Você pode acessar criando uma conta com email ou automaticamente com sua conta do github. É bem simples.
Após fazer login, no canto superior direito, clique no botão new project e, depois no botão import from github. Cole o link do repositório do projeto na modal que vai abrir e espere o build ficar pronto. É super rápido.

Ao finalizar o build você verá a tela com todos os arquivos do projeto.
No cabeçalho, clique no botão share e então teremos acesso à url da nossa aplicação.

Pronto. Essa url já pode ser usada nos seus projetos com todas as funcionalidades do Json-Server!

Vale lembrar que, o glitch por ser grátis, demora uns segundos pra responder no primeiro acesso. Mas isso não vai atrapalhar sua aplicação.

Deploy na Vercel

Assim como o Glitch, a Vercel também é uma plataforma muito utilizada para páginas e aplicações web. Se você nunca usou para subir um projeto ou, quer criar uma conta, sugiro esse artigo da Angela Caldas sobre Como colocar um projeto no ar com Vercel.

Conta criada, vamos seguir com o deploy da nossa api. Para hospedar na vercel precisamos fazer uma alteração no nosso repositório. Vamos adicionar um novo arquivo na raiz do nosso projeto e commitar pro github. Garanta que o arquivo se chame vercel.json.

{
  "version": 2,
  "builds": [
    {
      "src": "server.js",
      "use": "@vercel/node",
      "config": {
        "includeFiles": ["db.json"]
      }
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "server.js"
    }
  ]
}

Garanta que o nome do arquivo dentro de "includeFiles", seja o mesmo do arquivo de database do projeto. No nosso caso db.json. E agora nosso repositório está assim:

Feito isso, agora já podemos fazer o deploy na Vercel. Primeiro, no canto superior direito vamos clicar no botão Add New e, depois no link Project.

Em seguida, vamos procurar o nosso projeto na lista de respositórios e clicar no botão import. Na tela de build é possível editar o nome do projeto que vai estar na url da aplicação. Para finalizar vamos clicar no botão deploy. Agora é só aguardar o build ficar pronto.

Agora já temos a url da nossa api. Clique no banner e você será redirecionado para a tela de sucesso do Json-Server. E terá acesso a url da api para usar nos seus projetos com todas as funcionalidades do Json-Server!

Conclusão

Como vimos é bem fácil e rápido hospedar nossas apis de testes e estudos. Aqui eu trouxe duas alternativas simples e que resolvem o problema de quem precisa fazer requisições GET/PUT/POST/DELETE nas suas aplicações. Se você conhece alguma outra forma de hospedar uma aplicação, coloque nos comentários para ajudar a comunidade.

Grande abraço !!!