Noções Básicas de Endpoints
Criar um Endpoint
APIs, clique no botão Novo Endpoint.1.
2.
3.
4.
5.
Modo Design-first
Modo Request-first
Modos da Interface
Caminho do Endpoint
/users). O URL base é definido no ambiente, e o Apidog adiciona-o automaticamente ao efetuar pedidos para o endpoint./. Isto mantém o design da sua API limpo e organizado, e garante que tira pleno partido das funcionalidades do Apidog.Porquê Iniciar Caminhos com /
/ é recomendado para aderir à OAS. Não iniciar caminhos com / pode levar a vários problemas de compatibilidade ao utilizar ferramentas no ecossistema OpenAPI./ no início dos caminhos permite utilizar a funcionalidade de mock de padrão de URL, essencial para fins de teste e validação no Apidog.Método do Pedido
| Método | Descrição |
|---|---|
| GET | Obtém recursos especificados sem efeitos secundários. Utiliza parâmetros de consulta para transmitir dados. |
| POST | Submete dados para processamento e pode ter efeitos secundários. Normalmente, os dados são enviados no corpo do pedido. |
| PUT | Atualiza ou substitui integralmente recursos especificados. |
| DELETE | Remove recursos especificados. |
| OPTIONS | Consulta os métodos HTTP suportados pelo recurso de destino. |
| HEAD | Semelhante a GET, mas obtém apenas os cabeçalhos da resposta. Útil para verificar a existência e modificações de recursos sem descarregar o conteúdo do recurso. |
| PATCH | Atualiza informação parcial de recursos especificados. |
| TRACE | Devolve o pedido recebido pelo servidor. Utilizado principalmente para fins de depuração e diagnóstico. |
| CONNECT | Estabelece um túnel para o servidor, normalmente utilizado para encaminhamento de pedidos por servidor proxy. |
Metadados do Endpoint
| Campo | Descrição |
|---|---|
| Nome | Um nome descritivo que resume a funcionalidade do endpoint. |
| Estado | O estado predefinido é "Em desenvolvimento". Pode modificá-lo para refletir diferentes fases, como Teste ou Produção. Saiba mais sobre o estado do endpoint. |
| Responsável pela manutenção | Especifica o membro da equipa Apidog responsável pelo endpoint. Selecione um utilizador da sua conta para atribuir esta função. |
| Etiquetas | Palavras-chave ou expressões que categorizam ou descrevem o endpoint. Pode criar novas etiquetas ou selecionar a partir das existentes. |
| Serviço | O URL base ao qual o caminho do endpoint é acrescentado. Está definido por predefinição como "Herdar dos pais", mas pode ser especificado manualmente através das definições do ambiente. Saiba mais sobre Ambientes e serviços. |
| OperationId | Um identificador único (operationId na OAS) que distingue esta operação dentro da API. |
| Descrição | Informação detalhada sobre o objetivo e a utilização do endpoint, com suporte para Markdown para formatação melhorada. |
Campos Personalizados
Pedido
Parâmetros do Pedido
Parâmetros de Consulta
?, e separados por & da seguinte forma: ?id=2&status=available. São utilizados para filtrar, ordenar ou modificar a saída de um endpoint de API.INFO
Parâmetros de Caminho
/pets/{id}, Exemplo incorreto: /pets/:id.{parameter} no URL e, em seguida, utilizar {{variable}} para o valor do parâmetro. Por exemplo:Recomendado: Coloque a variável no valor do parâmetro de caminho
Não recomendado: Coloque a variável diretamente no URL
Não Confunda {parameter} com {{variable}}
{parameter}: Chavetas simples representam parâmetros de caminho no Apidog. Os parâmetros de caminho são marcadores de posição no caminho do URL que mudam dinamicamente para valores específicos quando o endpoint de API é acedido.{{variable}}: Chavetas duplas incluem variáveis nos pedidos. Estas variáveis podem ser substituídas por valores reais quando o pedido é enviado, permitindo entradas dinâmicas e personalizáveis nas interações com a API.Porquê NÃO Utilizar {{variable}} no Caminho
{{variable}} não adere à OAS. Seguir a OAS permite uma integração fluida com uma variedade de ferramentas no ecossistema OpenAPI.{{variable}} no caminho impedirá a utilização da funcionalidade de mock de padrão de URL no Apidog.Parâmetros de Cabeçalho
Saiba Mais
Parâmetros de Corpo
Saiba Mais
Descrever Parâmetros
string, integer, boolean, etc.), necessidade (obrigatório ou opcional) e quaisquer valores predefinidos ou restrições.| Propriedade | Descrição |
|---|---|
| Nome | Especifica o nome do parâmetro que está a ser descrito. É um campo obrigatório e deve representar com precisão o parâmetro que está a ser definido. |
| Tipo | Especifica o tipo de dados do valor do parâmetro. Os valores comuns incluem string, number, integer, boolean, array, object e outros. Esta propriedade ajuda a definir o formato e a estrutura do valor do parâmetro. |
| Descrição | Fornece uma breve explicação ou documentação sobre o parâmetro. Ajuda os utilizadores a compreender o objetivo e a utilização do parâmetro. |
| Obrigatório | Especifica se o parâmetro é obrigatório para o pedido de API. É um valor booleano (true ou false) que indica se o parâmetro deve ser incluído no pedido. |
| Definições Avançadas | Define o tipo de dados, o formato e as restrições do parâmetro. Permite-lhe fornecer informação detalhada sobre a estrutura e o conteúdo esperados do valor do parâmetro. |
Editor de Tipos
Esquemas
JSON ou XML, a estrutura de dados tem de ser definida. A estrutura de dados pode referenciar os esquemas.Saiba Mais
Resposta e Exemplo
| Componente | Descrição |
|---|---|
| Código de Estado HTTP | Determine todos os estados de resposta potenciais que o seu endpoint pode devolver, incluindo respostas padrão como 200 (OK), 404 (Not Found) ou 500 (Server Error). |
| Formato dos Dados | Defina o formato da resposta que a API devolverá para cada código de estado. Pode ser em JSON, XML, HTML, Raw, Binary ou qualquer outro formato adequado. |
| Esquema | Para respostas que transportam dados (principalmente estado 200), detalhe a estrutura do payload da resposta. Isto inclui especificar tipos, objetos aninhados, campos opcionais e arrays. Definições claras ajudam os programadores cliente a compreender que dados devem esperar e como analisá-los. Apenas JSON e XML podem configurar esquemas. Para informação detalhada, consulte Esquemas. |
| Exemplo | Fornecer uma resposta de exemplo é essencial para ilustrar como a API se comporta em cenários reais. Idealmente, um exemplo deve ser um conjunto de dados de amostra devolvido pelo servidor quando o endpoint é chamado com um pedido predefinido. Deve refletir a estrutura, o formato dos dados e os tipos conforme definidos pelo esquema da resposta. |
Adicionar Respostas
200 OK variem frequentemente entre vários endpoints devido a necessidades distintas de dados de saída, as respostas de erro, como 400 Bad Request e 404 Not Found, tendem a ser consistentes entre diferentes endpoints. O Apidog resolve de forma inteligente esta característica comum com a funcionalidade Componente de Resposta, que permite reutilizar respostas de erro predefinidas, tornando o processo de documentação da API mais eficiente e o comportamento da API mais consistente.Componentes de Resposta
Adicionar Exemplos de Resposta
Geração Automática de Exemplos
Pré-visualizar o Endpoint
Modified at 2026-06-09 08:54:45