Versões comparadas

Versão antiga 5

changes.mady.by.user Letícia FR Lima (Unlicensed)

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user cleilton.souza (Unlicensed)

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Índice
minLevel1
maxLevel7

Os padrões de Open Banking Finance podem não cobrir todas as possibilidades de objetos retornados ou APIs que os participantes desejam expor. Os participantes podem ter o desejo de realizar inovações sobre os padrões definidos oferecendo mais dados afim de atender demandas específicas de mercado. É nossa intenção que os padrões definidos não apenas permitam estas extensões como também sirvam como base para futuras alterações na própria definição dos padrões.

...

Participantes que desejam estender os padrões devem adicionar seu prefixo para identificar todas as extensões. Campos adicionais no retorno de endpoints existentes ou em novos endpoints devem usar o prefixo do participante. O prefixo deve ser criado no formato exposto ao lado (4 letras) e não devem haver seguinte formato: “EXT-”, seguidos por 4 letras, não devendo existir prefixos duplicados entre os participantes. Veja o exemplo Abaixo:

  • Exemplo de instituição fictícia: “EXT-FICT”

Nesta documentação, quando tivermos que nos referir ao prefixo do participante, o termo <PID> será utilizado.

Exemplos de Código

Cada participantes terá um ID que representa a sua instituição. Os participantes da na atual versão estão listados deverão atualizar seus PIDs para contemplar o novo formato de PID conforme exemplo apresentado abaixo:

  • EXT-BBAS - Banco do Brasil

  • EXT-BBCD - Bradesco

  • EXT-BTGP - BTG Pactual

  • EXT-CAIX - Caixa Econônica Federal

  • EXT-ITAU - Itau

  • EXT-STDR - Santander

  • EXT-BRGS - Banrisul

  • EXT-BNBR - Banco do Nordeste do Brasil

  • EXT-BNDS - BNDES

  • EXT-CITI - Citibank

  • EXT-SAFR - Safra

  • EXT-BABV - Votorantim

Novas APIs

...

Para os endpoints definidos dentro da estrutura acima, os atributos dos payloads não precisam conter o prefixo do participante, pois entende-se que todos os recursos da API estendida não conflitam de nenhum modo com as definidas pelo padrão. 

Importante:

  • Este método não deve ser usado para criar duplicações modificadas dos *endpoints* já definidos no padrão.

  • Os novos *endpoints* devem atender às convenções e princípios do padrão, incluindo convenções de nomes e tipos de dados.

 

Novos endpoints em APIs existentes

...

Se o participante deseja adicionar um novo endpoint que resume as transações por um período, então este endpoint poderia ser definido como: <host>/open-banking/accounts/v1/accounts/{account ID}/<PID>-balance-movement

 Importante:

  • O prefixo deve ser adicionado antes do nome do recurso seguido por um hífen. (-)

  • Como o *endpoint* é novo, os atributos do *payload* de requisição e resposta não precisam conter o prefixo do participante.

  • Se um *endpoint* possuir múltiplos níveis na URI do recurso, apenas o recurso mais a direita deverá possuir o prefixo do participante.

  • Os novos *endpoints* devem atender às convenções e princípios do padrão, incluindo convenções de nomes e tipos de dados.

Campos de retorno adicionais em um endpoint existente

...

Se um objeto estiver sendo adicionado ao payload de resposta, apenas o nome do objeto precisa receber o prefixo. Qualquer atributo dentro do novo objeto pode ser nomeado normalmente.

 Importante:

  • Campos existentes não devem ser modificados. Isto inclui adicionar novas opções em campos do tipo Enum.

  • Um campo obrigatório não deve se tornar opcional como resultado de uma extensão.

  • *Payloads* de requisição também podem ser estendidos, porém o resultado ainda deve respeitar os padrões definidos caso o campo de extensão não tenha sido utilizado (por definição, campos adicionais no *payload* de *request* devem ser opcionais).

  • Parâmetros de *query* podem ser adicionados desde que seguidas as mesmas premissas de um novo campo no *payload* de requisição (com prefixo, não obrigatório e sem efeitos colaterais caso não seja informado).

  • Parâmetros por *header* podem ser adicionados desde que seguidas as mesmas premissas de um novo campo no *payload* de requisição. No entanto, seu prefixo deve estar no formato `x--`.

  • Novos campos devem atender os padrões definidos de nomenclatura e tipos de dados.

Parâmetros query adicionais

...

Extensão do versionamento

Como descrito na seção versionamento, o versionamento existe apenas no nível das APIs e não no nível dos endpoints, no entanto caso seja necessário realizar versionamento de um endpoint customizado, o participante poderá utilizar o header x-<PID>-v para que o consumidor possa especificar qual versão do endpoint está requisitando.