почему спокойный дизайн означает дифференцировать создание и обновление?

Question

Я делаю одностороннее приложение для передачи данных из MS Access в приложение Rails. Я сохраняю приложение Rails спокойным, поэтому я говорю своему коллеге, что приложению Access необходимо отслеживать, была ли запись уже отправлена ​​в приложение Rails, потому что приложению Access потребуется идентификатор этой записи в приложении Rails, чтобы сделать "обновление". Он сомневался, что это необходимо, так как если, например, Access отправляет запись в модель Rails Person с идентификатором модели приложения Access, давайте назовем его AID, поэтому, если приложение Rails "видит" входящие ": name => 'John Doe ',: aid => 123 "и не находит такой модели Person с' AID ', равной 123, тогда Rails должен просто создать ее, а когда он найдет модель Person с' AID ', равной 123, затем обновить ее .

Я сказал ему, что дизайн спокойный, и «хорошо» держать два отдельных вызова (один с почтой и один с положением); тот, у которого 'put', нуждается в идентификаторе записи, которую вызов обновляет.

Но у него есть кое-что хорошее, почему мы дифференцируем создание и обновление, но не объединяем их одним способом, при котором проверка того, есть ли уже запись, может определить, будет ли это создание или обновление?

Спасибо!

Answer 1

Более подробное описание было дано по следующей ссылке относительно POST и PUT:

http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/

В аналогии с SQL POST - это INSERT с автоматически сгенерированным первичный ключ, а PUT является вставкой, которая определяет первичный ключ в оператор INSERT.

Разница, вероятно, не имеет значения, если все ваши первичные ключи генерируются автоматически. Различие существует для тех, кто желает, чтобы клиент мог выбрать первичный ключ, например, если он не просто целое число (возможно, GUID или текстовый идентификатор).

Answer 2

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

Как я понимаю, чтобы он знал, вызывать ли Create или Update, это будет означать, что ему потребуется либо

1. отслеживай, звонил ли он Создайте уже (что означает, что вы не могу удалить запись в Rails приложение, не сказав ему)
2. ему нужно спросить приложение Rails, является ли данные уже находятся в системе, и затем вызовите правильный API.

Оба варианта отстой.

Еще одна вещь, которую нужно добавить. Это не означает, что ваша служба должна всегда сначала проверять, существует ли запись. Если вы ожидаете, что ваше использование будет сильно искажено для одной операции (то есть обновления происходят часто, но вставка происходит редко), то, вероятно, имеет смысл «предположить, что запись есть, и выполнить обновление, если произойдет сбой, т.к. там, затем сделайте вставку ".

Answer 3

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

Во многих случаях было бы фатальным, если бы вслепую обновляли (и, следовательно, перезаписывали) запись, когда создание не удавалось из-за того, что был найден повторяющийся идентификатор.

Если это не относится к вашему приложению и никогда не будет в будущем, я бы сказал, что на самом деле было бы неплохо объединить создание и обновление - или, возможно, сохранить методы создания и обновления, но предоставить 3. api что делает и то, и другое.