Hace poco hablé sobre la API Headhunter para publicar trabajos, mencionando Superjob. Ahora, habiendo implementado la misma funcionalidad en la API de Superjob, será justo compartir su experiencia con usted.
Trabajando con la API Superjob
Por lo tanto, existe la tarea de publicar vacantes en Superjob, necesitará:
Versión API actual
Aquí se espera todo: el control de versiones está presente y se pasa en la URL:
https://api.superjob.ru/:version/method_name/:params
Registro de solicitud
Además, el procedimiento más simple es crear una cuenta, crear una aplicación, obtener tokens. Sin expectativas registro y SMS .
redirect_uri , pasado en los parámetros, aparentemente, no está asociado en absoluto con la URL de devolución de llamada especificada en la configuración de la aplicación. Ni siquiera se puede especificar (URL de devolución de llamada), todo funcionará.
También
Especificar parámetros requeridos
Las responsabilidades, los requisitos y las condiciones son parámetros opcionales de la vacante, pero el nombre de la empresa y una descripción de sus actividades deben transferirse a cada vacante.
La última vez (en HeadHunter) hubo un intento de publicar el enlace dentro de la vacante, aquí se encontró el parámetro url , sin embargo, no fue posible entender dónde aparece en la vacante.
Solicitar un enlace a una vacante creada
En lugar del superjob / vacantes / id esperado, el enlace se forma en forma de vacancy-name-id.html, pero solo el id de vacante viene en la respuesta. El texto en ruso está transcrito por un algoritmo desconocido (o de acuerdo con uno de los N GOST), lo que hace que sea imposible formar un enlace de su lado. Debe realizar una solicitud por separado para la ruta API desde donde ya se ha devuelto el enlace completo.
Elija entre horario de trabajo y tipo de empleo
Superjob combina estos dos campos, ofreciendo de la lista, por ejemplo, a tiempo parcial o parcial. Esto es inconveniente cuando hay temporizadores de fiestas, contratos a plazo fijo y otros escenarios.
Resumen
La última vez, mencioné que las vacantes en HeadHunter admiten HTML y un editor WYSIWYG se atornilla en el sitio para esto. Además de la tarea de publicar enlaces en vacantes (que fallaron ligeramente), también llegó la tarea de fijar WYSIWYG para ellos en nuestra aplicación. El texto de la vacante junto con el formato se guarda en la base de datos, por lo que de la misma manera voló a Superjob, que HTML no admite. En principio, se espera, pero el fakap principal es que después de mirar la misma vacante en HeadHunter, ¡resultó que tampoco admite el formato enviado! Las etiquetas simplemente se eliminan y el texto desnudo permanece en la salida. Como resultado, WYSIWYG se eliminará, y todas las vacantes registradas con HTML deberán analizarse y limpiarse en tres bases de datos de alguna manera.
Me gustaría escribir muchas malas palabras sobre la contratación externa, pero en otro momento.
Acerca de la conveniencia
Si comparamos HeadHunter y Superjob, es obvio que con este último, todo es mucho más simple. La integración se creó muy rápidamente: los textos de error no eran confusos, todo se probó en varios entornos debido a la URL de devolución de llamada opcional.
Lo que me molestó fue la falta de una API Superjob en Github, pero allí me divertí con un "cliente simple" en PHP por mil quinientas líneas. Hay comentarios para comunicarse con el soporte técnico, sin embargo, en la forma de una apelación, no hay una categoría de preguntas por parte de API. Bueno eso.
Conclusión
En general, difícilmente se puede decir inequívocamente que alguien es mejor, alguien es peor. Superjob tiene algo de qué quejarse, pero al final, el servicio proporciona una API normal que resuelve completamente nuestros problemas.