Atualmente, a maioria das APIs é diferenciada com base no método e caminho. No entanto, alguns projetos de desenvolvimento (como alguns documentos de API de comércio eletrónico) utilizam um URL fixo para o pedido da API e diferenciam as APIs através de parâmetros em Query / Cabeçalho.Após a versão 2.2.9, o Apidog adicionou a funcionalidade de identificação única de endpoint, que suporta OperationId, parâmetros de Query, parâmetros de Corpo e parâmetros de Cabeçalho como parâmetros para diferenciar APIs.
O ID único de endpoint é definido ao nível do diretório. Quando precisar de definir uma API como uma identificação única, tem de fazê-lo no respetivo diretório principal. Clique no diretório e escolha o parâmetro de identificação única de acordo com as suas necessidades; depois de clicar em guardar, a definição terá efeito em todas as APIs desse diretório.
Para este exemplo, vamos escolher o parâmetro de Query e escrever OperationID no nome do parâmetro.
Depois de definir a identificação única de endpoint para o diretório, clique numa API desse diretório, clique no separador operationid e, tanto nas informações básicas como nos parâmetros do pedido na parte inferior da API, existe um ícone K, que representa o parâmetro para o ID único de endpoint.
Pode introduzir o valor correspondente no parâmetro correspondente como o valor da identificação única de endpoint.
Se utilizar parâmetros em Query/Cabeçalho para distinguir APIs no seu projeto e importar um ficheiro em formato OpenAPI para o Apidog, será apresentada a página seguinte.A regra para corresponder APIs durante a importação está sujeita às definições do diretório de destino. Se a definição da identificação única de endpoint no diretório de destino não cumprir os requisitos, pode modificá-la nas definições de importação. Após a modificação, terá efeito diretamente no diretório de destino.Como exemplo, vamos importar este diretório e criar um ID único de endpoint para o mesmo com Parâmetro de Query e Nome do Parâmetro chamado action.
Lembre-se: se o seu diretório já tiver um ID único, a nova importação não o pode substituir.
Notas Importantes
1.
Os utilizadores que tenham utilizado o Valor Fixo nos parâmetros de Query não precisam de se preocupar, porque esta função continuará a ser mantida. No entanto, ao importar, o Valor Fixo é avaliado com base no URL, pelo que se recomenda que os utilizadores que tenham utilizado o Valor Fixo utilizem a identificação única de endpoint.
2.
A identificação única de endpoint suporta a definição de vários parâmetros.
3.
Se apenas um subdiretório no seu diretório estiver definido como identificação única de endpoint, ao importar Swagger e atualizar todos os diretórios, evite importar todos os projetos para o diretório raiz para atualização. Recomenda-se importar separadamente as APIs definidas como identificação única de endpoint para esse diretório especial.
A partir da versão 2.2.24, se a API tiver definido o identificador único como Parâmetro de Corpo ou Parâmetro de Cabeçalho, tem de enviar o caminho + nome e valor do parâmetro do identificador único para obter os Dados Mock correspondentes.
Boas Práticas de Dados Mock
1.
Ao aceder a Dados Mock durante o desenvolvimento, os programadores frontend também precisam de enviar o caminho + nome e valor do parâmetro do identificador único se a API tiver definido o identificador único como Parâmetro de Corpo ou Parâmetro de Cabeçalho.
2.
Para projetos que tenham um identificador único para APIs, a documentação da API tem de ser normalizada para evitar casos em que as APIs tenham o mesmo URL, mas não tenham um identificador único definido. Isto destina-se a evitar falhas na obtenção correta de Dados Mock.
