我最近谈论了用于发布工作的Headhunter API ，其中提到了Superjob。 现在，已经在Superjob API上实现了相同的功能，因此可以与您分享经验。
使用Superjob API
因此，有一项任务是在Superjob上发布职位空缺，您将需要：
当前的API版本
一切都在这里-版本存在并在URL中传递：
https://api.superjob.ru/:version/method_name/:params
申请注册
同样，最简单的过程是创建帐户，创建应用程序，获取令牌。 没有期望 注册和短信 。
显然，在参数中传递的redirect_uri与应用程序设置中指定的回调URL根本没有关联。 它（回调URL）甚至都无法指定，一切正常。
也一样
指定必需的参数
职责，要求和条件是空缺的可选参数，但是公司名称及其活动说明必须转移到每个空缺。
上一次（在HeadHunter上）尝试在空缺内发布链接，在这里找到了url参数，但是，我们无法理解它在空缺中的位置。
请求链接到已创建的空缺
该链接以vacancy-name-id.html的形式形成，而不是预期的superjob /职位/ id，但是响应中仅包含职位ID。 俄语文本已通过未知算法（或根据N个GOST之一）进行音译，从而无法在其一侧形成链接。 您必须从已返回完整链接的地方单独请求api路由。
在工作时间表和就业类型之间进行选择
Superjob结合了这两个字段，例如列表中提供的兼职或兼职。 当有聚会计时器，定期合同和其他情况时，这很不方便。
总结
上次，我提到HeadHunter的职位空缺支持HTML，并且为此目的在网站上安装了WYSIWYG编辑器。 除了发布职位空缺的链接（略有失败）的任务之外，在我们的应用程序中为它们固定所见即所得的任务也到达了。 空缺文本以及格式设置将保存在数据库中，因此以与飞入HTML不支持的Superjob相同的方式进行存储。 原则上是可以预期的，但是主要的缺点是在HeadHunter上看到相同的空缺后，事实证明它也不支持发送格式！ 标记只是被删除，并且裸文本保留在输出中。 结果，所见即所得将被删除，并且所有记录的HTML空缺都需要以某种方式在三个数据库中进行解析和清理。
我想写很多关于外包的坏话，但是另一些时间。
关于便利
如果将HeadHunter和Superjob进行比较，很明显，与后者相比，一切都简单得多。 集成建立起来非常迅速-错误文本没有引起混淆，由于可选的Callback URL，所有内容都在几种环境下进行了测试。
令我不高兴的是，Github上缺少Superjob API，但在那里，我用一千五百行的PHP的“简单客户端”玩得很开心。 尽管有与技术支持进行沟通的反馈，但是，以申诉的形式，API并没有类别的问题。 好吧
结论
总的来说，很难说一个人更好，一个人更糟。 Superjob值得抱怨，但是最后，该服务提供了一个完全解决我们问题的普通API。