Uma breve história sobre nosso serviço de recrutamento personalizado e uma grande história sobre os problemas que surgiram ao integrar-se ao HeadHunter em termos de postagem de vagas. Porquê HeadHunter? Porque no Superjob, tudo é um pouco mais simples (mas mais sobre isso mais tarde).
Antecedentes
Minha equipe está desenvolvendo um aplicativo de colocação de emprego baseado na Web para uma grande cadeia de varejo. A cadeia de ações é construída desta maneira:
- a empresa aprova os modelos básicos de vagas (requisitos, responsabilidades, condições), universais para todas as lojas e cidades;
- Os RHs, com base no modelo básico, criam o modelo básico de vaga para cada cidade, indicando a faixa salarial para uma posição específica (para cargos idênticos em regiões diferentes, pode haver salários diferentes);
- o diretor da loja, com base no modelo de vaga, abre uma vaga em sua loja dentro do nosso aplicativo e recebe um link para ele;
- o candidato, seguindo o link, chega ao questionário, onde insere as informações de contato e as envia ao diretor da loja para consideração;
- ??????
- LUCRO!
Quando houve uma proposta para publicar uma vaga no HeadHunter com um link para o questionário, estudei fluentemente a documentação da API e pensei em algo no estilo de "existe um negócio por 5 minutos". E agora, após ~ 1,5 meses, estou escrevendo este artigo.
Trabalhando com a API HeadHunter
Portanto, há a tarefa de publicar vagas no HeadHunter, você precisará de:
Versão atual da API
Infelizmente (ou felizmente?), A API não é versionada; portanto, teoricamente , qualquer coisa pode cair a qualquer momento. Mesmo que isso nunca tenha acontecido e não haja pré-requisitos para isso, ele ainda será atualizado:
Você pode encontrar chaves nas respostas e nos parâmetros da API que não estão descritos na documentação. Normalmente, isso significa que eles são deixados para compatibilidade com versões mais antigas. Seu uso não é recomendado.
Registro do aplicativo
Tudo é simples aqui, mas não tão simples quanto gostaríamos. Você será solicitado a preencher um formulário em que um dos campos contenha a expressão " Descreva todas as funcionalidades do aplicativo e indique os métodos de API utilizados ". Quão detalhado ???
Ao registrar o aplicativo pela primeira vez, o formulário foi preenchido em detalhes, indicando todas as rotas; na segunda vez, houve paciência suficiente apenas para a frase " todos os métodos do bloco de vagas ". Ambas as opções foram aprovadas.
O pedido é aprovado por cerca de duas semanas. Essa é uma das razões pelas quais nossa integração se arrastou um pouco.
Registro da segunda aplicação
Preste atenção ao parâmetro Redirect URI ao registrar o aplicativo. De acordo com nossa observação, confirmada pelo suporte técnico do HeadHunter, se seu circuito de teste estiver localizado em um subdomínio (por exemplo, test.example.com), será necessário um aplicativo para venda (com redirect_uri = example.com) e para desenvolvimento (com redirect_uri = test.example.com ) E são mais duas semanas aguardando aprovação.
Aprendendo e esclarecendo as regras
Enquanto desenvolvíamos as vagas fechadas funcionais e publicadas no modo de teste, tudo estava bem. Após o download de vagas abertas para a publicação de publicações, os links desapareceram devido à proibição pelas regras de sua colocação em vagas, mas, por palavras de apoio, os links podem ser enviados automaticamente ao usuário em resposta (o que não é descrito nas regras). Aqui ficamos decepcionados com o nosso próprio descuido, no entanto, na minha opinião, foi possível colocar um validador no estágio de recebimento do texto da vaga.
Um pouco de intuição
Às vezes, os textos de erro são completamente imprevisíveis e ilógicos. Aqui está o que enfrentamos:
not_enough_purchased_services (serviços adquiridos para publicar ou atualizar este tipo de vaga não são suficientes) - ao publicar uma vaga com o tipo livre . O que exatamente precisa ser comprado para vagas gratuitas não está claro. Solução: especifique o type: standard ;quota_exceeded (a cota do gerente para publicar este tipo de vaga terminou) - as cotas do gerente são configuradas através de https://hh.ru/employer/settings/quotas , a última vez que o vimos ao digitar standart vez de standard no campo type ;duplicate (uma vaga semelhante já foi publicada) ao usar o sinalizador ignore_duplicates - ocorre quando os campos de name e area são os mesmos, independentemente da presença do sinalizador para ignorar duplicatas.
Tambem
Sobre segurança
Leve em consideração o fato de que a vida do token é de duas semanas (aparentemente é a hora favorita) e você não pode atualizá-lo antes do tempo, apenas pelo razlogin. Teoricamente, isso não deve causar problemas; no entanto, se o token vazar, o invasor poderá ter tempo suficiente para refletir, atrocidades e se gabar.
Sobre interfaces
Uma descrição do trabalho é um campo de description único que suporta várias tags HTML, mas a formatação funciona apenas quando publicada no site. HTML enviado via API transformado em texto sem formatação.
Sobre livros de referência
Como toda a API, os diretórios podem mudar a qualquer momento, conforme explicitamente declarado em suas descrições:
Também são possíveis erros, por exemplo, no diretório de regiões encontradas espaços em excesso, para os quais você pode não estar pronto. Comecei uma revisão sobre esse tópico, espero que eles o consertem, mas tenha cuidado.
Sumário
Um início rápido levará cerca de duas semanas, provavelmente com a necessidade de registrar vários aplicativos. Em geral, a documentação e a própria API são bastante sãs; caso contrário, você pode descobrir como se comunicar com o suporte técnico ou através de problemas no github.
Tenho certeza de que não encontramos todas as coisas interessantes relacionadas à API do HeadHunter, porque nem tocamos no ramo de currículo. Portanto, se você tem algo a dizer / complementar / esclarecer - escreva nos comentários.
PS
API do Superjob e uma pequena comparação com o HeadHunter: habr.com/en/post/465663