Здравствуйте, samius, Вы писали:

Pzz>>Сам по себе запрос — это просто транспорт неких данных. Он не может быть идемпотен или нет. В спецификации протокола HTTP просто нет такого слова.
S> 9.1.2 Idempotent Methods

Ну ОК. В спецификации есть.

Здравствуйте, Pauel, Вы писали:
P>Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
P>Это БЛ. Все остальное есть просто реализация вот такого требования.
Позволю себе не согласиться. Бизнес-аналитики вообще не должны мыслить вот этими категориями технических подробностей.
Есть бизнес-сценарий. Например — заказ такси.
Бизнес аналитик в первую голову анализирует функциональные потребности. Ну там — будем ли мы в рамках одного заказа давать ехать через N точек, или это строго A->Б?
Можно ли разделить оплату на нескольких пассажиров, или мы требуем строго 1 поездка = 1 плательшик?
А одному плательщику можно оплатить заказ частично картой, частично кэшем? А двумя картами?
Можно ли отменить заказ? А если водитель уже приехал? А если начал выполнение заказа?
Что делать, если клиент не выходит, но заказ не отменяет?
В какой момент списывать деньги — в начале поездки? В конце? Что, если поездка прервана посередине?

В первую голову, естественно, идут т.н. "позитивные" сценарии.
Потом начинаем критически смотреть на это — нет ли в нашей бизнес-логике дырок. Типа: таксист никуда не поехал, а тупо нажал "я прибыл", дождался "невыхода" клиента, получил компенсацию от сервиса, и побежал "брать" другой заказ. Или, например, наоборот — клиент вызывает такси, и за 30 секунд до прибытия машины отменяет заказ, и так 100 раз.
Или мы списали с клиента 100р за первый сегмент, начинаем списывать 500 за второй — а у нас отказ банка.

Изо всего этого строится большое-большое дерево решений; на их основе формируется набор требований.
Вот эти все подробности "ой, а что делать, если во время поездки рубануло питание датацентра?" — это вообще не вопрос бизнес-логики. Бизнес-аналитик (по крайней мере, в нормальной компании) не должен объяснять solution architect вещи типа "ребяты, надо все изменения держать в персистентной СУБД, и вся интеграция с внешними сервисами должна уметь восстанавливаться после сбоя".
И точно так же вопросы идемпотентности конкретных методов находятся в ведении архитекторов.
Это то же самое, как если бы аналитик должен был в каждом use-case добавлять строчку "а ещё программа должна работать корректно".
Или, к примеру, диктовал, какой протокол выбирать.
Если бы BA проектировал сервис типа DNS, то он бы наверняка большое внимание уделил таким вещам, как семейства записей и топология доменных зон.
Вещи типа TTL уже обсуждались между BA и архитекторами, которые бы объясняли, что для обеспечения нужного уровня надёжности база должна быть распределена, поэтому прямое управление кэшированием лучше игры в угадайку.
В процессе обсуждения в бизнес-логику проникли бы концепции вроде авторитативных и не-авторитативных ответов.
А вот вещи типа выбора UDP вместо TCP в качестве протокола, а также детали того, как клиент понимает, какой из пакетов ответа относится к какому запросу, вообще бы целиком решались на уровне архитекторов.
Это нифига не часть "бизнес-логики". Бизнес-логика там ровно та же, что и в HTTP — есть запрос, есть ответ. А вот какие конкретно будут методы в HTTP, или коды ошибок, или структура и нумерация UDP-пакетов — это слишком низкий для BL уровень.

Здравствуйте, Sinclair, Вы писали:

S>Это нифига не часть "бизнес-логики". Бизнес-логика там ровно та же, что и в HTTP — есть запрос, есть ответ. А вот какие конкретно будут методы в HTTP, или коды ошибок, или структура и нумерация UDP-пакетов — это слишком низкий для BL уровень.

Хорошо, я согласен, идемпотентность не относится к бизнес-логике.
Вот у нас есть два варианта реализации операции, что выберешь?

Явный контроль идемпотентности

@Post('/orders')
operation(order: Delta<Order>, idempotencyKey: string): Promise<Order>

Магический

@Post('/orders')
@Idempotent()
operation(order: Delta<Order>): Promise<Order>

Здравствуйте, Pauel, Вы писали:
P>Хорошо, я согласен, идемпотентность не относится к бизнес-логике.
P>Вот у нас есть два варианта реализации операции, что выберешь?

P>Явный контроль идемпотентности
P>

P>@Post('/orders')
P>operation(order: Delta<Order>, idempotencyKey: string): Promise<Order>
P>

P>Магический
P>

P>@Post('/orders')
P>@Idempotent()
P>operation(order: Delta<Order>): Promise<Order>
P>

Без контекста — непонятно.
Чтобы идемпотентностью пользоваться, нужен какой-то код обвязки вызовов на клиенте.
То есть, мы не просто делаем где-то в коде клиента httpClient.PostAsync(orderServiceUrl, orderUpdateContent). Нам надо
1. Записать в локальную базу инфу о том, что "worflow #xxxxxxx is going to update the order #yyyyyyy, idempotence key #kkkkk, update params $pppppppp".
2. Попытаться выполнить тот самый POST, или PUT, или PATCH
3. В зависимости от результата либо перейти по успешной ветке, либо по ветке неудачи, либо вернуться на шаг 2.

Как у нас устроен клиент? Возможно, все эти шаги — часть магии некоего фреймворка или workflow engine. Тогда мы в прикладном коде вообще идемпотентность не описываем; с его точки зрения, в сигнатуру вызова входит только прикладные части операции. А вопросы прозрачного сохранения состояния workflow в базу, восстановления после сбоев, ретраев и прочие подробности от прикладного программиста скрыты. Заодно лишая его возможности напороть в реализации.

Дальше — а как устроен сервер? Вот вы написали аннотацию метода, а дальше что?
Будете ли вы вручную выполнять сравнение пришедших в order параметров с актуальной версией, и сохранять значение ключа идемпотентности в базу?
Или, опять таки, будет работать некая магия фреймворка, которая за вас вычислит ETag, LastModified date, а заодно вытащит из запроса ключ идемпотентности и сравнит его с кодом за вас?

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

Ну, и, опять же, операция — операцией, а есть ещё и расположение аргументов. Раз уж мы рисуем разметку, которая привязывает наш operation к глаголу HTTP, то и аргументы этой операции могут приехать из url (path или query), из тела, или из какого-то хидера. Прикладному сервера это всё равно, а вот с точки зрения клиентов и, в том числе, совместимости между разными версиями протокола это может быть важно.

Здравствуйте, Pauel, Вы писали:


P>Вот у нас есть два варианта реализации операции, что выберешь?

P>Явный контроль идемпотентности
P>

P>@Post('/orders')
P>operation(order: Delta<Order>, idempotencyKey: string): Promise<Order>
P>

P>Магический
P>

P>@Post('/orders')
P>@Idempotent()
P>operation(order: Delta<Order>): Promise<Order>
P>

Простите, а контроль со стороны кого?
Клиента? Сервера? Программиста?

Это все работает не так как вы думаете.
Вот вы делаете АПИ, а я пытаюсь его использовать. Мы оба читали спецификации.
Я вижу метод PUT и понимаю что могу спокойно добавить код повтора запроса если получил ошибку 5xx или вообще не получил ответа из-за проблем сети. В случае с POST это в общем случае не так.

Увидев в сигнатуре метода idempotencyKey я могу сделать предположение что метод будет идемпотентным, но это будет завесить от семантики payload. Если это JSON Patch, то у меня будут закрадываться сомнения, что метод действительно идемпотентный и я могу спокойно повторять вызов с одними и теми же параметрами.

Кроме того, с точки зрения тестирования явное указание idempotencyKey скорее всего приведет к том, что при тестировании в postman будут менять payload и не будут менять idempotencyKey с абсолютно непонятными последствиями.

Поэтому я бы рекомендовал отказаться от идемпотентности POST с JSON Patch и аналогичным payload.

Здравствуйте, gandjustas, Вы писали:

G>Простите, а контроль со стороны кого?
G>Клиента? Сервера? Программиста?

Всех участников

G>Это все работает не так как вы думаете.
G>Вот вы делаете АПИ, а я пытаюсь его использовать. Мы оба читали спецификации.
G>Я вижу метод PUT и понимаю что могу спокойно добавить код повтора запроса если получил ошибку 5xx или вообще не получил ответа из-за проблем сети. В случае с POST это в общем случае не так.

POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.

G>Увидев в сигнатуре метода idempotencyKey я могу сделать предположение что метод будет идемпотентным, но это будет завесить от семантики payload. Если это JSON Patch, то у меня будут закрадываться сомнения, что метод действительно идемпотентный и я могу спокойно повторять вызов с одними и теми же параметрами

При чем здесь json patch и почему какая с ним проблема?

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:

G>>Простите, а контроль со стороны кого?
G>>Клиента? Сервера? Программиста?

P>Всех участников
И как клиент может проконтролировать?


G>>Это все работает не так как вы думаете.
G>>Вот вы делаете АПИ, а я пытаюсь его использовать. Мы оба читали спецификации.
G>>Я вижу метод PUT и понимаю что могу спокойно добавить код повтора запроса если получил ошибку 5xx или вообще не получил ответа из-за проблем сети. В случае с POST это в общем случае не так.

P>POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.
Как клиент может узнать, что POST на определенный уорл внезапно стал идемпотентным

G>>Увидев в сигнатуре метода idempotencyKey я могу сделать предположение что метод будет идемпотентным, но это будет завесить от семантики payload. Если это JSON Patch, то у меня будут закрадываться сомнения, что метод действительно идемпотентный и я могу спокойно повторять вызов с одними и теми же параметрами

P>При чем здесь json patch и почему какая с ним проблема?
При том, что это более-менее стандартный способ описать дельту изменений. Но он поддерживает страшные операции вроде add\remove\copy

Здравствуйте, gandjustas, Вы писали:

P>>Всех участников
G>И как клиент может проконтролировать?

Клиенту нужно выполнить свои обязанности

P>>POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.
G>Как клиент может узнать, что POST на определенный уорл внезапно стал идемпотентным

Из описания API. Обычно клиент генерируется, а не пишется руками.

P>>При чем здесь json patch и почему какая с ним проблема?
G>При том, что это более-менее стандартный способ описать дельту изменений. Но он поддерживает страшные операции вроде add\remove\copy

Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:

P>>>Всех участников
G>>И как клиент может проконтролировать?
Какие обязанности у клиента?

P>Клиенту нужно выполнить свои обязанности

P>>>POST не запрещено делать идемпотентным. Например, вызов функции в ODATA это POST, но это спокойно можно сделать идемпотентным.
G>>Как клиент может узнать, что POST на определенный уорл внезапно стал идемпотентным
P>Из описания API. Обычно клиент генерируется, а не пишется руками.
В каком описании присутствует информация об идемпотентности тех или иных вызовов?


P>>>При чем здесь json patch и почему какая с ним проблема?
G>>При том, что это более-менее стандартный способ описать дельту изменений. Но он поддерживает страшные операции вроде add\remove\copy

P>Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?
Я не очень понимаю что значит "поддерживает" когда мы говорим об операциях вроде add-remove-copy. В зависимости от порядка выполнения набора add-remove-copy результат может быть разный. еЕли мы повторяем вызовы, то порядок выполнения не будет совпадать с изначальным порядком вызовов.

Здравствуйте, gandjustas, Вы писали:

P>>>>Всех участников
G>>>И как клиент может проконтролировать?
G>Какие обязанности у клиента?

Обычные — сделать запрос в соответствии с его семантикой. Если АПИ говорит о том, что операция идемпотентна, то на клиенской стороне надо сделать N соответствующих приседаний. Разумеется, это все делается самим клиентом по метаданным, а не вручную отсылая запрос POST.

P>>Из описания API. Обычно клиент генерируется, а не пишется руками.
G>В каком описании присутствует информация об идемпотентности тех или иных вызовов?

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

P>>Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?
G>Я не очень понимаю что значит "поддерживает" когда мы говорим об операциях вроде add-remove-copy. В зависимости от порядка выполнения набора add-remove-copy результат может быть разный.

Что мешает зафиксировать этот порядок или вообще убрать эти add-remove-copy?

> еЕли мы повторяем вызовы, то порядок выполнения не будет совпадать с изначальным порядком вызовов.

Как то странно выполнять приседания пачкой каждый раз. Если хочешь, что бы батч, а add-remove-copy, это фактически батч, был идемпотентным, то надо приложить чуть больше усилий, чем просто выполнять каждый раз и ждать того же результата.
Например, порядок должен быть зафиксирован, эта пачка операций идет внутри транзакции, и выполняется ровно один раз, не больше, и не меньше. Отсюда не ясно, как ты собиаешься получить "разный" результат.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:

G>>>>И как клиент может проконтролировать?
G>>Какие обязанности у клиента?
P>Обычные — сделать запрос в соответствии с его семантикой. Если АПИ говорит о том, что операция идемпотентна, то на клиенской стороне надо сделать N соответствующих приседаний. Разумеется, это все делается самим клиентом по метаданным, а не вручную отсылая запрос POST.
Какие метаданные сообщают клиенту что операция идемпотента?

G>>В каком описании присутствует информация об идемпотентности тех или иных вызовов?
P>Я привел описание, вернись и посмотри. Выглядит так, будто ты накидываешь не читая.
Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.
Что ты привел — я не знаю. Если ты сам делаешь и клиент и сервер, то можешь использовать любые методы как угодно.

P>>>Что не так с этими операциями? Вот есть у тебя ключ x-y-z, метод POST и кучка add-remove-copy. Если сервер поддерживает идемпотентность для этой операции, то какие проблемы?
G>>Я не очень понимаю что значит "поддерживает" когда мы говорим об операциях вроде add-remove-copy. В зависимости от порядка выполнения набора add-remove-copy результат может быть разный.
P>Что мешает зафиксировать этот порядок или вообще убрать эти add-remove-copy?
P>Как то странно выполнять приседания пачкой каждый раз. Если хочешь, что бы батч, а add-remove-copy, это фактически батч, был идемпотентным, то надо приложить чуть больше усилий, чем просто выполнять каждый раз и ждать того же результата.
P>Например, порядок должен быть зафиксирован, эта пачка операций идет внутри транзакции, и выполняется ровно один раз, не больше, и не меньше. Отсюда не ясно, как ты собиаешься получить "разный" результат.
Это уже правильный путь. Если сделать несколько шагов, то получится PUT на урл с ключом и полным "объектом" в теле, без всяких дельт.

Здравствуйте, fmiracle, Вы писали:

F>Это можно сделать каким-то промежуточным слоем, который будет отрабатывать для всех запросов вообще и одинаково. Но значение ключа при этом тогда гораздо удобнее держать не частью бизнес-данных запроса, а чем-то техническим — хидер для rest, или поле в конверте, например, если у нас какой-то свой протокол.

F>При появлении нового запроса в АПИ достаточно будет прописать тот же хидер и вся магия для него заработает сразу, без каких-то правок. А если уж вдруг для каких-то запросов "стандартный" механизм не подходит, то убрать этот общий хидер и делать отдельно на урвоне бизнес-логики.

Да, тут вопрос в некоторой мета-договорённости. Для PUT такая мета-договорённость присутствует в самом протоколе, почему он и крут. Для всего остального надо привинчивать ручками.
Для меня это выглядит некоторым аналогом авторизации. Вот у нас сейчас стандартом де-факто является авторизационный токен, который передаётся в хидере Authentication.
При этом лично у меня нет никакого желания делать его явным параметром метода бизнес-логики.
Бизнес-аналитик пишет в требованиях "этот метод требует наличия роли XXX у вызывающего". И логично это описывать в виде каких-то аннотаций на метод на стороне сервера, а не делать явный параметр authenticationToken, который потом реализатор должен как-то обработать прикладным кодом.

Здравствуйте, gandjustas, Вы писали:

P>>Обычные — сделать запрос в соответствии с его семантикой. Если АПИ говорит о том, что операция идемпотентна, то на клиенской стороне надо сделать N соответствующих приседаний. Разумеется, это все делается самим клиентом по метаданным, а не вручную отсылая запрос POST.
G>Какие метаданные сообщают клиенту что операция идемпотента?

Например, атрибут @Idempotent() над определением операции. Или обязательный параметр idempotency key который помечет соответствующим атрибутом.
Все что нужно от клиента — одинаковые параметры должны давать тот же самый реквест вне зависимости от последовательности вызовов.

G>Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.

А я разве говорил про сваггер? Я же дал описание, ты его проигнорировал.

G>Что ты привел — я не знаю. Если ты сам делаешь и клиент и сервер, то можешь использовать любые методы как угодно.

В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.

G>Это уже правильный путь. Если сделать несколько шагов, то получится PUT на урл с ключом и полным "объектом" в теле, без всяких дельт.

Совсем необязательно. Идемпотентность нужна вне зависимости от транспорта. Т.е. может оказаться так, что нет ни post, ни put, ни вообще http, а REST и идемпотентность операции остаются.
Сейчас в норме сервсисы унутре конторы коммуницируют не только через http. Зачем мастырит чтото особенное, если для той же декларации АПИ можно просто подкинуть другой транспорт?
И клиентский, и серверный код останутся без изменений.
Даже если ты перейдешь на graphql, это не избавит тебя от обеспечения идемпотентности.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:

G>>Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.
P>А я разве говорил про сваггер? Я же дал описание, ты его проигнорировал.
Это описание в каком формате?
Я вот пишу на С#, хочу сделать клиент для твоего rest api. Что ты мне отдашь? Куда мне засунуть твое описание, чтобы сгенерировался клиент?


G>>Что ты привел — я не знаю. Если ты сам делаешь и клиент и сервер, то можешь использовать любые методы как угодно.
P>В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.
Как сервер будет проверяться на следование гарантиям? Я не очень понимаю.

Здравствуйте, gandjustas, Вы писали:

G>>>Ты не понял вопроса: какое описание получает клиент? В лучшем случае это swagger. В нем никак не указывается идемпотентность методов.
P>>А я разве говорил про сваггер? Я же дал описание, ты его проигнорировал.
G>Это описание в каком формате?

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

G>Я вот пишу на С#, хочу сделать клиент для твоего rest api. Что ты мне отдашь? Куда мне засунуть твое описание, чтобы сгенерировался клиент?

Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.

P>>В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.
G>Как сервер будет проверяться на следование гарантиям? Я не очень понимаю.

Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?

Здравствуйте, Pauel, Вы писали:

P>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
И как определить что параметр это именно ключ идемпотентности? По имени? Или есть какой-то способ в swagger или другой формальной спецификации (WSDL, proto) указать какой параметр является ключом?

P>Какая именно проблема у тебя тут возникла?
Проблема определения ключа идемпотентности

G>>Я вот пишу на С#, хочу сделать клиент для твоего rest api. Что ты мне отдашь? Куда мне засунуть твое описание, чтобы сгенерировался клиент?
P>Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.
Меня смущает, что ты не можешь назвать в какой формальной спецификации ты отдаешь описание методов. Ты старательно обходишь этот вопрос, что намекает, что у тебя нет ответа на него.

P>>>В том то и дело. Только делать самому и то, и другое необязательно. Достаточно предоставить гарантии, что метаданные понимает и клиент, и сервер, и оба следуют им.
G>>Как сервер будет проверяться на следование гарантиям? Я не очень понимаю.

P> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
В случае PUT есть соглашение более высокого уровня, чем твое описание (которое кстати нет пока еще). Это означает что и клиент и сервер, даже не договариваясь между собой, смогут воспользоваться преимуществами идемпотентности.

P>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
Odata вполне соответствует REST, и идемпотентность там только для PUT и DELETE, для POST её нет. Также нет способа в рамках EDMX описать идемпотентные методы помимо PUT и DELETE.

Здравствуйте, Pauel, Вы писали:

P>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
Нет. В PUT ключом идемпотентности выступает ровно URL ресурса. Так описано в спеке на HTTP.

P>Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.
Проблема — в том, что семантика рукопашного ключа идемпотентности описана где-то в тексте, который нужно прочитать глазами, и реализовать паттерн идемпотентного доступа руками.
В одном АПИ ключ поедет в хидере, в другом АПИ — в теле, в третьем — вовсе придумают его в query string.

P> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
Нет, но клиент может полагаться на идемпотентность PUT в силу RFC 2616.

P>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
А вы уже посмотрели, как именно операции делаются идемпотентными в той же ODATA?

Здравствуйте, gandjustas, Вы писали:

P>>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
G>И как определить что параметр это именно ключ идемпотентности? По имени? Или есть какой-то способ в swagger или другой формальной спецификации (WSDL, proto) указать какой параметр является ключом?

А как ты определяешь, что параметр является именем пользователя, идентификатором, емейлом, суммой для списания со счета?
А correlation ты как определяешь?

P>>Какая именно проблема у тебя тут возникла?
G>Проблема определения ключа идемпотентности

Ровно то же самое, что и с аргументом любой другой семпантики.

G>Меня смущает, что ты не можешь назвать в какой формальной спецификации ты отдаешь описание методов. Ты старательно обходишь этот вопрос, что намекает, что у тебя нет ответа на него.

Ужос, и исходный код я тоже не выкладываю!!!!!11111йййqqq Все ответы дадены. У тебя по существу пока ничего нового нет.

P>> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
G>В случае PUT есть соглашение более высокого уровня, чем твое описание (которое кстати нет пока еще). Это означает что и клиент и сервер, даже не договариваясь между собой, смогут воспользоваться преимуществами идемпотентности.

Правильно понимаю, то самое "соглашение высокого уровня" само себя запроектирует, закодит, зафиксит баги, протестирует, продеплоит и всё само себя?

P>>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
G>Odata вполне соответствует REST, и идемпотентность там только для PUT и DELETE, для POST её нет. Также нет способа в рамках EDMX описать идемпотентные методы помимо PUT и DELETE.

Так и есть — PUT сам себя обеспечит гарантиями, доведет до прода сам себя, да еще и баги от юзеров сам будет репортать.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:

P>>>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
G>>И как определить что параметр это именно ключ идемпотентности? По имени? Или есть какой-то способ в swagger или другой формальной спецификации (WSDL, proto) указать какой параметр является ключом?

P>А как ты определяешь, что параметр является именем пользователя, идентификатором, емейлом, суммой для списания со счета?
По имени параметра. Ты предлагаешь тоже по имени это делать?

P>А correlation ты как определяешь?
Это что?

P>>>Какая именно проблема у тебя тут возникла?
G>>Проблема определения ключа идемпотентности
P>Ровно то же самое, что и с аргументом любой другой семпантики.
Нет, ключом идемпотентности в PUT и DELETE является url


G>>Меня смущает, что ты не можешь назвать в какой формальной спецификации ты отдаешь описание методов. Ты старательно обходишь этот вопрос, что намекает, что у тебя нет ответа на него.
P>Ужос, и исходный код я тоже не выкладываю!!!!!11111йййqqq Все ответы дадены. У тебя по существу пока ничего нового нет.
Теперь понятно

P>>> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
G>>В случае PUT есть соглашение более высокого уровня, чем твое описание (которое кстати нет пока еще). Это означает что и клиент и сервер, даже не договариваясь между собой, смогут воспользоваться преимуществами идемпотентности.
P>Правильно понимаю, то самое "соглашение высокого уровня" само себя запроектирует, закодит, зафиксит баги, протестирует, продеплоит и всё само себя?
ни одно соглашение этого не сделает

P>>>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
G>>Odata вполне соответствует REST, и идемпотентность там только для PUT и DELETE, для POST её нет. Также нет способа в рамках EDMX описать идемпотентные методы помимо PUT и DELETE.
P>Так и есть — PUT сам себя обеспечит гарантиями, доведет до прода сам себя, да еще и баги от юзеров сам будет репортать.
Так как odata сервис в основном пишется людьми, которые читали RFC, то ты можешь рассчитывать, что PUT и DELETE там будут идемпотентными, а POST — не будет. Это еще до получения edmx.
Более того, даже если сделают какой-то метод в edmx, который будет вызываться с помощью POST и будет идемпотентен, то ты об этом не узнаешь, потому что в EDMX нет этой информации.
Кроме случаев если в параметрах метода явно написан idempotencyKey, но тогда непонятно почему бы не вынести этот ключ в url и не использовать PUT.

Короче снова пришли к тому, что идемпотентность POST в общем случае не нужна и приседания с её реализацией не имеют смысла.

Здравствуйте, Sinclair, Вы писали:

P>>Ключ идемпотентности в любом описании апи это явный обязательный параметр.
S>Нет. В PUT ключом идемпотентности выступает ровно URL ресурса. Так описано в спеке на HTTP.

Урл нам надо сначала отрендерить
Вот PUT в ODATA протоколе, который REST искаропки

PUT /Warehouse.svc/Orders('an-id')

Вызываем его примерно так:

svc.orders.update('an-id', modifiedOrder);

или так:

svc.orders.update(modifiedOrder);

Т.е. у нас явный параметр, который и будет ключом идемпотентности. Для POST мы этот ключ можем положить куда угодно, это непринципиально.

P>>Что тебя смущает? Ты внятно сформулируй проблему. А то у тебя какие то намёки, страхи, но ничего конкретного нет.
S>Проблема — в том, что семантика рукопашного ключа идемпотентности описана где-то в тексте, который нужно прочитать глазами, и реализовать паттерн идемпотентного доступа руками.
S>В одном АПИ ключ поедет в хидере, в другом АПИ — в теле, в третьем — вовсе придумают его в query string.

Куда поедет ключ — дело десятое. Есл клиент генерируется по метаданным, а наружу торчит OO-интерфейс, нам это вообще по барабану, где что лежит. Вылезла пробелема с гатевеем, которй не пропускает наш запрос — поменяли атрибут, добавили @Header или @Encode и всё путём — перебилдили, и всё палит. Не надо вообще думать, что там где на самом деле лежит.

P>> Ты предложил использвать идемпотентный PUT. В твоём случае, надо полагать, идемпотентность сама себя обеспечит, напишет дизайн документы, наструячит код, покроет тестами всех уровней, проведет демо и задеплоится?
S>Нет, но клиент может полагаться на идемпотентность PUT в силу RFC 2616.

Клиент — может. А на сервере это нужно мейнтейнить руками. Например, какой то шутник решит, что раз изменений нету, то можно и ошибку бросить "already done". И тесты надо написать, что бы такой шутник убедился, что его подход невалидный.

P>>Если ты умеешь обеспечить идемпотентны PUT, то какая именно проблема в том, что бы сделать идемпотентной операцию, например, в той же ODATA ?
S>А вы уже посмотрели, как именно операции делаются идемпотентными в той же ODATA?

Что касается одаты, то я запилил серверный фремворк для TypeScript поверх оdata протокола собственной разработки, так что вобщем одату понимаю. Кое что портироал на жээс из odata-olingo, кое что из дотнета, остальное допилил самостоятельно. Собственно, это мой текущий проект — кучка фремворков на разные случаи жизни.
Идемпотентность реализуется ровно так же, как и везде. И на graphql нам она тоже нужна, и на grpc тоже. Например, апи будет торчать — openapi, odata, graphql, grpc. Незачем мучиться и пилить всё под каждый протокол. У нас только контроллеры будут разные, а всё остальнео будет в общем коде, и там же идемпотентность будет сидеть.
Вот например кейс такой, что нам надо проавать апи и юезр будет выбирать протокол и платить за количество фактически вызваных операций. А он возьми и выбери graphql. Разве мы ему скажем, что теперь про идемпотентность он должен забыть?