Ответ
1) однозначное сопоставление с тем, что у нас храниться, для возможности автоматической валидации актуальности и обновления.
2) метод findById не ищет по наименованию. вариант первоначальный поиск делать по suggest, при выборе например филиала, нам надо взять расширенные данные, для этого нам опять же надо однозначно сопоставить по уникальному ИД в данном случае hid.
с ходу два примера :)
Да, примеры хорошие ツ Минус один — мы не гарантируем, что hid не изменится в будущем. Если это для вас ОК, то можно передавать значение hid в запросе findById/party — будет работать.
Моя задача, выбор организации пользователем и сохранение в базе. Решение:
- выбрать организацию из результатов /suggest/party
- передать hid на сервер
- запросить на сервере организацию по hid /findById/party, сохранить данные организации в БД
Т.е. без hid никуда. Может быть вы знаете лучше решение?
Нормальный вариант, если вы не полагаетесь на hid как на «долгоживущий» идентификатор.
> Минус один — мы не гарантируем, что hid не изменится в будущем.
не изменилась ли случаем позиция по поводу изменчивости hid в будущем?
если он по-прежнему может измениться... каков примерный/минимальный срок жизни?
дни, недели, месяцы, ...
Сервис поддержки клиентов работает на платформе UserEcho
Да, примеры хорошие ツ Минус один — мы не гарантируем, что hid не изменится в будущем. Если это для вас ОК, то можно передавать значение hid в запросе findById/party — будет работать.