Pull to refresh
2
0
Alex Davidovich @alxsad

Software Engineer

Send message

Как написали выше, констрейнты бд это больше про консисетнси данных. Бизнес проверки лучше делать в коде, так как они могут измениться и легче будет изменить код, нежели чем строить новые триггеры в бд.

А можно узнать почему такой констрейнт необходимо сделать именно на стороне бд? Имхо, это бизнес логика и она должна решаться кодом. Можно в одной транзакции сразу получить количество валидных купонов и вставить новый купон только если количество равно 0, иначе закрыть транзакцию.

дженерики надо было использовать :)

Думаю, пора заканчивать этот тред, превращается в "разница существенна", "нет, разница не существенна" :)

Ну так чем вам PATCH не "стандарт"-то?

Я где-то утверждал обратное?

В описании REST прописано, что для полного обновления ресурса используется PUT, для частичного - PATCH. Вы выбрали у себя частично обновление с помощью PATCH, потому что вам надо частично обновлять, ок. Почему PUT плохой?

Из-за "легких" аналогий новички делают неверные выводы. Человек который читает наш тред может сделать вывод "писать api на rest это наверное как написать игру на ассемблере,". Но ведь это не так, разница не существенна даже для больших систем.

REST предназначен для проектирования API, но для сложной логики он не подходит

Ну вот опять, что значит не подходит, подходит :)

Давайте сначала. Вы утверждаете что в некоторых кейсах PUT неудобно использовать и лучше подходит PATCH. Я утверждаю что проблема не в PUT, а лучше придерживаться "спецификации" REST, и проектировать апи "правильно". Вы вольны использовать любой http метод для вашего удобства, но это уже неявно и вы получите какое-то количество проблем из-за этого в будущем. Да даже простой пример, будут приходить новые люди в команду и вы будете каждый раз рассказывать почему выбрали PATCH и почему отошли от "стандартов".

Извините, но чем POST /doc/{id}/diffs принципиально отличается от PATCH /doc/{id}?

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

Так в том-то и дело, что никакой особой магии как правило и не требуется! Патчи-то обратно совместимы.

Я за свои 15+ лет в разработке, ни разу не встречал такого подхода и проблему с PUT, а вы говорите что никакой магии. А видел и проектировал я ооочень много апишек.

Но ведь это вы играете словами, сравнение совсем некорректное, микроскоп не предназначен для забивания гвоздей, а вот REST как раз таки предназначен для проектирования API :)

вам надо сначала научиться передавать на бекенд изменения в сущностях

Я до сих пор не понимаю ваш поинт про PUT и одновременное редактирование, возможно вы имеете ввиду кейс когда есть что-то типа "два юзера редактируют страницу и надо синкать ее состояние", в это случае вам не PUT /doc/{id} надо делать, а POST /doc/{id}/diffs cо своим набором полей.

А потом все эти версии поддерживать.

Поддерживать систему - это часть работы команды разработки. Версионировать лучше чем писать магическую логику обработки полей для всех типов клиентов - старых и новых. Хотя бы все явно получается, а как мы все знаем явное лучше неявного.

Я хорошо понимаю что всегда есть трейдофф - между "удобно" и "сложно поддерживать", но еще есть мир больших корпоративных систем, где выбор обычно падает на удобочитаемость, понятность, логичность, поддержку стандартов и так далее.

Микроскопом тоже можно гвозди забивать, но все-таки он для этого не подходит.

В данном случае REST совсем не микроскоп, а разновидность молотка.

Мне кажется, любой, кто делал бэкенд с достаточно сложной бизнес-логикой, быстро приходит к выводу, что REST для бизнес-логики не подходит.

Нет, вы утверждали что REST не подходит для сложной бизнес-логики, а я утверждаю обратное :)

Во-первых, одновременное редактирование.

Не понимаю причем здесь одновременное редактирование? Это вообще отдельный вопрос транзакций/уровней изоляции/блокировок и тд.

Во-вторых, обратная совместимость API. Что делать, если у ресурса появились дополнительные атрибуты, про которые клиент не знает, а потому не может передать?

Версионировать API

Если вы ни разу не встречали этой проблемы - значит, либо вы никогда не сопровождали готовый продукт, либо у вас не было мобильных клиентов.

Чего я только не видел за свои 15 лет.

Насколько я понимаю, в вашем примере links это немного другое, в тексте говориться о такой штуки как HATEOAS, где в состояние ресурса еще включат секцию links с возможным набором действий с этим ресурсом. В любом случае, наш спор превращается в типичный "этот язык круче, нет этот". На вопрос "зачем" отвечу что вы вольны делать как угодно, удобнее RPC подход, окей, но есть еще и такой подход как REST и мой поинт в том что любое апи можно написать используя данный архитектурный подход. Разные подходы не противоречат друг другу, всегда есть trade-off.

А у PATCH никакой проблемы и нет, она есть у PUT.

Ни разу не встречал проблем и с PUT.

Из того же restfulapi.net.

1.2. Collection and Sub-collection Resources

resource may contain sub-collection resources also.

For example, sub-collection resource “accounts” of a particular “customer” can be identified using the URN “/customers/{customerId}/accounts” (in a banking domain).

Similarly, a singleton resource “account” inside the sub-collection resource “accounts” can be identified as follows: “/customers/{customerId}/accounts/{accountId}“.

и еще штук 10 разных действий

В вашем случае я не видел такого количества действий, думаю, это искусственное предположение, которое можно решить введением поля metada, где можно складывать специфичные для каждого action поля. Но, повторюсь, это крайний случай, которого быть не должно при грамотном проектировании доменного слоя.

Если вы хотите придерживаться Representational State Transfer, то обязательно. Если не хотите, тогда непонятно, почему нельзя просто сделать "POST /articles/{id}/decline".

Мы создаем подресурс через POST /articles/{id}/states, соответсвенно и получаем весь список с помощью GET /articles/{id}/states.

С помощью POST /articles/{id}/states мы создаем условно "action log" сущность, частью которой легко может являться поле reason. Тут полное соответствие REST. Например, когда мы сделаем такой запрос


POST /articles/{id}/states

{"type":"declined", "reason":"text from moderator"}

на бэкенде мы проставим посту статус draft.

И на GET /articles/{id} необязательно возвращать массив states. Все зависит от случая.

Все так, ничего не мешает использовать PUT вместо POST, но зачем? У данного подхода есть и минусы. Например, придется в коде ветвить логику когда запись новая и когда уже существует. Еще может поменяться логика генерации идентификаторов, в случае с POST легко меняется на бэкенде.

PATCH используется для частичного изменения ресурса, он не обнуляет поля сущности, которые отсутсвуют в запросе в отличие от PUT. Из restfulapi.net:

"The PATCH method is not a replacement for the POST or PUT methods. It applies a delta (diff) rather than replacing the entire resource."

Я в своей практике ни разу не встречал проблем с совместимостью PATCH. Думаю, данная проблема уже давно неактуальна.

Значит не правильно понял. Тогда такой вариант должен подойти

POST /articles/{id}/states

{"type":"published"}

{"type":"declined", "reason":"text from moderator"}

и сохранять эти мутации стейтов, которые будут менять и стейт поста

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Registered
Activity