Uso de APIs Senior X (públicas x privadas)

  • # 2 anos atrás

    Devido a última mudança nas APIs públicas (uso do clientId nas requisições), nosso time de desenvolvedores da WeDo Tecnologia levantou algumas dúvidas. São elas:

    – Uso das APIs por aplicações externas (projetos desenvolvidos por nós): Atualmente usamos as APIs identificadas na documentação como privadas, por exemplo a https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/platform/user/queries/getUser. Esse tipo de API é destinada apenas ao uso interno (ecossistema Senior X)?
    Para nós desenvolvedores, o uso dessa API é incorreto?
    Quais os impactos além de não ser informado sobre possíveis alterações?

    – Uso do clientId nas requisições (APIs públicas): Já foi virada a chave?
    Ainda conseguimos realizar requisições sem o clientId. Caso a chave não tenha sido virada, qual a previsão?

    E, sobre o e-mail disponibilizado para dúvidas (ecossistema@senior.com.br), este tem rejeitado informando que não estamos cadastrados na lista de remetentes autorizados.

    Abrimos um ticket #114715, mas este foi finalizado sem solução ou resposta satisfatória. Já que o não funcionamento do ecossistema@senior.com.br é um problema e deveria ser analisado.

    # 2 anos atrás

    Olá Lucas, tudo bem?

    A Senior tem o conhecimento de que, atualmente, a diferenciação das APIs públicas/privadas não está adequada e acaba gerando muitas dúvidas dos desenvolvedores externos.
    Justamente por isso estamos pensando em uma forma de facilitar essa identificação e consumo. Uma delas é termos todas as APIs abaixo de um único endpoint, que será o api.senior.com.br. Esperamos em breve ter uma solução adequada e, quando a tivermos, iremos comunicar novamente sobre estas mudanças.

    Quanto aos questionamentos:

    – Uso das APIs por aplicações externas (projetos desenvolvidos por nós): Atualmente usamos as APIs identificadas na documentação como privadas, por exemplo a https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/platform/user/queries/getUser. Esse tipo de API é destinada apenas ao uso interno (ecossistema Senior X)?
    Resposta: Recomendamos a utilização da “versão pública” da API sempre que esta estiver disponível. Neste caso, o ideal seria utilizar a versão cujo swagger está exposto neste endereço: https://api.xplatform.com.br/api-portal/pt-br/content/apis-senior. Note que o endpoint da versão pública acaba simplificando bastante:
    http://api.senior.com.br/platform/user/getUser

    Para nós desenvolvedores, o uso dessa API é incorreto?
    Resposta: Não é incorreto, até mesmo porque não temos todas as APIs expostas abaixo da URL api.senior.com.br – pelo menos por enquanto. Este é um dos intuitos do trabalho que comentei no início, de unificar o local das APIs públicas e privadas. Quando isto ocorrer, há uma possibilidade (que ainda é pequena) da Senior rever a abertura da chamada de APIs externas diretamente para o endpoint da plataforma (platform.senior.com.br). Assim sendo, o ideal é que sempre que for possível, o desenvolvedor externo deveria optar pela versão pública da API.

    – Uso do clientId nas requisições (APIs públicas): Já foi virada a chave?
    Resposta: Ainda não. Isto deverá ocorrer de fato a partir de amanhã (06/05/22). Estamos dando um tempo extra pro pessoal conseguir se ajustar.

    – Sobre o e-mail disponibilizado para dúvidas (ecossistema@senior.com.br), este tem rejeitado informando que não estamos cadastrados na lista de remetentes autorizados.
    Resposta: Vamos verificar com o nosso time de infra. Assim que tiver um retorno, comento aqui.

    Até mais.

    # 2 anos atrás

    Perfeito! Muito obrigado pela atenção e pelo rápido retorno.

    # 2 anos atrás

    Lucas, o envio de e-mail para ecossistema@senior.com.br está normalizado.

    Até mais.

    Luan Tavares
    Participante
    # 2 anos atrás

    Bom dia,

    Temos um fluxo no BPM que usa uma fonte de dados que se baseia em uma entidade publica. (https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/hcm/payroll/entities/person)

    Devido a esta exigência do client_id não estamos mais conseguindo realizar a consulta na fonte de dados, já gerei o client_id e via postman tudo certo, porém onde informo o client_id na fonte de dados do BPM?

    # 2 anos atrás

    Bom dia Luan, tudo bem?

    Fizemos um ajuste na forma de efetuar o repasse do client_id há uns dias, justamente para tratar este caso.

    Agora é possível informar o client_id também via query param.
    Ex: https://api.senior.com.br/platform/user/getUser?client_id=xhxhxhxhxhxhx

    Sugerimos repassar sempre o client_id através do header. Nos casos em que isso não é possível, pode-se utilizar o formato do query param.

    Luan Tavares
    Participante
    # 2 anos atrás

    Bom dia Roque,

    Deu certo, muito obrigado.

    # 1 ano, 9 meses atrás

    Boa tarde!
    Durante a migração de APIs privadas para públicas notamos uma diferença nos links gerados durante o processo de upload de arquivos na AWS.
    A API privada gera um link que ao ser clicado, abre o PDF na própria aba do navegador.
    Já pela API pública, o link gerado realiza o download do PDF de forma automática.

    Parece ser algo “bobo”, mas essa rotina é muito usada por nossos usuários/clientes. O download automático acaba gerando uma enorme quantidade de arquivos desnecessários no computador.

    Existe algum parâmetro na API pública para possibilitar a geração do link, da mesma forma que é gerado na API privada?

Visualizando 8 posts - 1 até 8 (de 8 do total)

You must be logged in to reply to this topic.