Comments 6
В ответе на «пагинированную» коллекцию по-хорошему ещё бы отдавать адреса ресурсов для получения следующей и предыдущей «страниц», если таковые имеются.
Ну и для всех интересующихся реализациями RESTful API — вот неплохая книга, для упорядочивания знаний: www.amazon.com/gp/product/B00890OBFI/ref=kinw_myk_ro_title
Ну и для всех интересующихся реализациями RESTful API — вот неплохая книга, для упорядочивания знаний: www.amazon.com/gp/product/B00890OBFI/ref=kinw_myk_ro_title
Со временем данные будут расширяться, всегда обеспечивая обратную совместимость.
Не так давно (кажется, это было в прошлую пятницу) столкнулся с проблемой. При парсинге резюме раньше поле gender содержало идентификатор пола (male, female). Начиная с некоторого времени gender стал приходить в виде объекта, содержащего id и человекочитаемое название пола. Зачем нужно второе — непонятно, ну и ладно. Главное, что это поломало существующий функционал.
Кстати, очень печально, что API описано так скудно: для полей не указывается хотя бы информация о максимальной длине поля, о его обязательности и о том, как поле передаётся в случае отсутствия значения (null или отсутствие поля). А по резюме так вообще почти никакой информации на странице описания API.
Формат выдачи резюме действительно на данный момент не описан в документации. Более того, на данный момент официально он не запущен, мы как раз готовимся его выпустить вместе с подробной документацией и дополнительными сервисами по созданию, редактированию и обновлению резюме. После публичного релиза формат, естественно, будет зафиксирован и дальнейшие обновления не будут ломать обратную совместимость. Как это сделано в случае сервиса вакансий и сервиса откликов.
Изменение формата поля «пол» было как раз фикс одного из последних багов: приведение в единый вид всех полей, значения которых доступны в справочниках (/dictionaries и т.п.)
Приносим свои извинения за то, что, возможно, сбили с толку, так как действительно в документации уже есть упоминание про выдачу резюме, но просим всегда разрабатывать, основываясь на документации, а не на текущих ответах сервера. Ответ всегда может содержать ошибку, когда как в документации описан контракт. В тех моментах, когда документации нет, сервис скорее всего находится в стадии релиз-кандидата и в него могут вносить правки.
Спасибо за замечание, добавим этот момент на страницу документации.
Вы разрабатываете приложение, использующее наш сервис резюме? Если у вас есть дополнительные вопросы, замечания, предложения, любой feedback, пишите на api@hh.ru — с удовольствием проконсультируем и учтём все ваши предложения по улучшению API.
Изменение формата поля «пол» было как раз фикс одного из последних багов: приведение в единый вид всех полей, значения которых доступны в справочниках (/dictionaries и т.п.)
Приносим свои извинения за то, что, возможно, сбили с толку, так как действительно в документации уже есть упоминание про выдачу резюме, но просим всегда разрабатывать, основываясь на документации, а не на текущих ответах сервера. Ответ всегда может содержать ошибку, когда как в документации описан контракт. В тех моментах, когда документации нет, сервис скорее всего находится в стадии релиз-кандидата и в него могут вносить правки.
Спасибо за замечание, добавим этот момент на страницу документации.
Вы разрабатываете приложение, использующее наш сервис резюме? Если у вас есть дополнительные вопросы, замечания, предложения, любой feedback, пишите на api@hh.ru — с удовольствием проконсультируем и учтём все ваши предложения по улучшению API.
Интересен рассказ и о серверной стороне построения API: как масштабируете, каковы нагрузки, создаваемые клиентами, используете ли обычные серверы веб-приложений или выделенные, есть ли кто-то за nginx-ом и тому подобное.
Sign up to leave a comment.
Миграция на новую версию API