K
Это разнаряд рабочий и танцор и жнец и на дуде игрец.
Size: a a a
2021 June 16
˸A
В маленькой компании в проекте с двумя программистами - ок
АГ
все верно, поэтому надо не расписывать задачи, а делать. ну а другие пусть мучаются в своем незнании и потихоньку обретают знания. тоже будут делать.
SP
В маленькой компании не нужен архитект
K
Тут стратегия какая должна быть. Нельзя говорить, помогать и советовать, направлять. Попытки развиться пресекать. Сам поймёт? Тогда хорошо. А пока, радость - в неведении.
A
SP
очередная бесполезная статья с кратким пересказом Эванса
2021 June 17
2021 June 18
П
Привет, нужен коллективный разум. Есть сервер клиент работает через RPC и обмениваются серилизованными java объектами. Делаю rest API. Получаю DTO и конвертирую в domain объект. И отдаю сервису. Сейчас дошел до метода executeOrder(OrderRequest)
В OrderRequest есть енамка Action и много полей. В зависимости от action используются разные поля из реквеста.
Вот думаю как лучше организовать API.
1. Создать для каждого action свой ендпоинт со своей DTO м нужными полями.
2. Повторить структуру domain объекта в DTO. Один ендпоинт принимает реквест по action делегирует выполнение команде(применю этот паттерн)
В OrderRequest есть енамка Action и много полей. В зависимости от action используются разные поля из реквеста.
Вот думаю как лучше организовать API.
1. Создать для каждого action свой ендпоинт со своей DTO м нужными полями.
2. Повторить структуру domain объекта в DTO. Один ендпоинт принимает реквест по action делегирует выполнение команде(применю этот паттерн)
П
В первом случае на каждый action свой метод API. Много методов.
Во втором случае клиенту нужно понимать какие поля при каком action передавать.
Во втором случае клиенту нужно понимать какие поля при каком action передавать.
DE
Удобнее много специализированных методов
OK
Первый. SRP во все поля, да и вадидация будет проще.
SP
Первый вариант - разные операции разные методы api
SP
По аналогии с любым rpc
П
Спасибо за ответы выше. Ещё уточнение, /api/orders/draft создает ордер, а потом обновляет его, пользователь последовательно заполняет и переходит по шагам. Каким должен быть метод POST или PATCH? Или два метода?
SF
PATCH - обновление
POST - создание
POST - создание
П
Спасибо кэп. Я потому и спрашиваю)
SF
Ты так сформулировал вопрос, что иначе его не понять…
П
Все нормально сформировано. Ожидается два варианта ответа.
1. Метод POST или PATCH
2. нужно два метода - каждый для своей задачи.
Конечно по логике два надо, но часто, даже в springData есть метод save() который либо создаёт либо обновляет запись. И он один. Вот насколько кашерно такое делать в REST API
1. Метод POST или PATCH
2. нужно два метода - каждый для своей задачи.
Конечно по логике два надо, но часто, даже в springData есть метод save() который либо создаёт либо обновляет запись. И он один. Вот насколько кашерно такое делать в REST API