J'ai récemment parlé de l'API Headhunter pour publier des emplois, en mentionnant Superjob. Maintenant, après avoir implémenté la même fonctionnalité sur l'API Superjob, il sera juste de partager votre expérience avec vous.
Travailler avec l'API Superjob
Donc, il y a la tâche de publier les offres d'emploi sur Superjob, vous aurez besoin de:
Version actuelle de l'API
Tout est attendu ici - le versioning est présent et passé dans l'URL:
https://api.superjob.ru/:version/method_name/:params
Enregistrement de l'application
De plus, la procédure la plus simple consiste à créer un compte, créer une application, obtenir des jetons. Sans attentes inscription et SMS .
redirect_uri , passé dans les paramètres, n'est apparemment pas du tout associé à l'URL de rappel spécifiée dans les paramètres de l'application. Il (URL de rappel) ne peut même pas être spécifié, tout fonctionnera.
Aussi
Spécifiez les paramètres requis
Les responsabilités, exigences et conditions sont des paramètres facultatifs du poste vacant, mais le nom de l'entreprise et une description de ses activités doivent être transférés à chaque poste vacant.
La dernière fois (sur HeadHunter), il y a eu une tentative de publication du lien dans la vacance, ici le paramètre url été trouvé, cependant, il n'a pas été possible de comprendre où il apparaît dans la vacance.
Demander un lien vers un poste créé
Au lieu du superjob / vacancies / id attendu, le lien est formé sous la forme vacancy-name-id.html, mais seul l'id de la vacance vient dans la réponse. Le texte russe est translittéré par un algorithme inconnu (ou selon l'un des N GOST), ce qui rend impossible de former un lien de son côté. Vous devez faire une demande distincte pour l'itinéraire api d'où le lien complet est déjà retourné.
Choisissez entre l'horaire de travail et le type d'emploi
Superjob combine ces deux domaines, proposant à partir de la liste, par exemple, à temps partiel ou à temps partiel. Cela n'est pas pratique lorsqu'il existe des minuteries pour les parties, des contrats à durée déterminée et d'autres scénarios.
Résumé
La dernière fois, j'ai mentionné que les postes vacants chez HeadHunter prennent en charge HTML et un éditeur WYSIWYG est vissé sur le site pour cela. En plus de la tâche de publier des liens dans les postes vacants (qui a légèrement échoué), la tâche de fixer WYSIWYG pour eux dans notre application est également arrivée. Le texte de la vacance ainsi que la mise en forme sont enregistrés dans la base de données, donc de la même manière, ils ont volé vers Superjob, que HTML ne prend pas en charge. En principe, il est prévu, mais le principal fakap est qu'après avoir regardé le même poste vacant sur HeadHunter, il s'est avéré qu'il ne prend pas non plus en charge le formatage envoyé! Les balises sont simplement supprimées et le texte nu reste dans la sortie. En conséquence, WYSIWYG sera supprimé et tous les postes vacants enregistrés avec HTML devront être analysés et nettoyés dans trois bases de données d'une manière ou d'une autre.
Je voudrais écrire beaucoup de mauvais mots sur l'externalisation, mais une autre fois.
À propos de la commodité
Si l'on compare HeadHunter et Superjob, il est évident qu'avec ce dernier, tout est beaucoup plus simple. L'intégration a été construite très rapidement - les textes d'erreur n'étaient pas déroutants, tout a été testé sur plusieurs environnements en raison de l'URL de rappel facultative.
Ce qui m'a bouleversé, c'est le manque d'une API Superjob sur Github, mais là je me suis amusé avec un "client simple" en PHP pour quinze cents lignes. Il y a un retour pour communiquer avec le support technique, cependant, sous la forme d'un appel, il n'y a pas de catégorie de questions par API. Eh bien, ça.
Conclusion
En général, on peut difficilement dire sans équivoque que quelqu'un est meilleur, que quelqu'un est pire. Superjob a de quoi se plaindre, mais au final, le service fournit une API normale qui résout complètement nos problèmes.