Является ли обычной практикой изменять тип данных в обработчике?

Изменение типа данных в обработчике (хэндлере) — это практика, которая зависит от архитектуры приложения и принципов, действующих в вашей команде или проекте. 

### Практика изменения типа данных

1. **Слой ответственности**: Обычно рекомендуется придерживаться принципа единой ответственности (Single Responsibility Principle). Хэндлеры часто отвечают за обработку входных данных, их валидацию и передачу в бизнес-логику (сервисы). Чем больше логики вы будете вставлять в хэндлеры, тем сложнее будет их поддерживать.

2. **Валидность данных**: Если id приходит в виде строки и вы хотите использовать UUID в вашем приложении, обычно стоит валидировать и преобразовывать тип данных на уровне сервиса. Это позволяет хэндлерам оставаться "тонкими", так как они будут лишь передавать данные, которые уже были нормально обработаны.

3. **Testability (Тестируемость)**: Если вы учитываете тестируемость вашего кода, то раздельные ответственности в хэндлерах и сервисах облегчают написание тестов. Хэндлеры можно тестировать отдельно, как и бизнес-логику в сервисах.

4. **Читаемость кода**: Лучше, когда хэндлеры проще и более "читаемы". Если вы будете выполнять много преобразований и проверок в хэндлерах, код может стать трудным для понимания.

### Рекомендации

- **Валидация**: Выполняйте валидацию входных данных в хэндлере, чтобы удостовериться, что данные имеют правильный формат, прежде чем передавать их в сервис.

- **Преобразование типов**: Лучше изменять типы данных в сервисах, где вы можете контролировать бизнес-логику. Это поможет сделать хэндлеры более чистыми и сфокусированными на их основной задаче — управлении запросами и ответами.

- **Обработка ошибок**: Если преобразование типов требует проверки (например, если строка не является допустимым UUID), стоит продумать, как обрабатывать такие ошибки и возвращать информативные сообщения пользователям.

В общем, разделение обязанностей и следование принципам чистой архитектуры поможет сохранить код более управляемым и понятным.

правильно ли изменять тип переменой (в данном случае id со string на uuid) в хэндлере, или это необходимо делать в сервисе?
 Зависит от ситуации, если без этого никак и особых проблем от смены не будет, то можно сразу в хендлере поменять. Если от этого изменения будут ломаться внешние клиенты, то тут придется уже по другому обходить эту проблему, например добавлять v2/api.

Я считаю, что десериализация данных должна делаться максимально близко ко входу в сервис, т.е. в http хендлере. 
 
 Мы сразу же сможем рано провалидировать этот UUID, и не будем передавать в слой бизнеса невалидные данные. Чем раньше происходит валидация, тем нам меньше работы. Валидация UUID - это обычная штука, она никак не связана с бизнес-логикой, так что абстракции не протекают, и есть смысл её делать в хендлере. 
 
 В хендлере вы должны принять строковое либо какое-то другое представление запроса и и преобразовать в данные, имеющие смысл для слоя бизнес-логики. 
 
 Думаю, для бизнес-логики имеет смысл оперировать уже UUID, а не строкой. 
 
 Теперь предположим, что нам нужно сделать дополнительно уже не http хендлер, а что-то, что будет получать на вход из другого пакета уже готовый UUID. Как-то нехорошо будет преобразовать этот UUID в строку и передавать в бизнес-логику эту строку только затем, чтобы там эта строка снова была преобразована в UUID.