Pull to refresh

Comments 95

UFO just landed and posted this here

Заголовки я поправил, а как спойлеры делать в новом редакторе я не нашёл.

Статусы 4xx означают, что клиент допустил ошибку

Апологеты REST с вами не согласятся.
404 — означает, что ресурс не найден, а причина, почему он не найден может приходить теле.
Возвращать 404 если в базе по какой-то причине отсутствует объект — это очень популярный подход в REST.
Именно — если _ресурс_ не найден — то, как по мне, ничего плохого в 404 нет.

В примере автора же — поиск, который не какой-то конкретный ресурс, которого может не быть. Он есть всегда и всегда успешен, даже если ничего не найдено — «ресурсом» в контексте REST в данном случае будет «результат поиска» (а он может быть и пустым), а не его содержимое. Пользователь/клиент здесь не ошибся. А вот попытка загрузить данные с URI несуществующего ресурса — вполне ошибка, поэтому 404.
В примере автора же — поиск, который не какой-то конкретный ресурс, которого может не быть

Поиск это ресурс, тоже. С собственной семантикой и представлением.

Тут вопрос терминологии. Я в этом контексте под «ресурсом» имел в виду «сущность», но, правда, не написал про отличие сущности от «фичи».

Можно сказать, что поиск — это ресурс со своей семантикой, и отличие тут как раз в том, что если какой-нибудь заказ (/orders/{order_id}) — это ресурс-сущность, поиск — это ресурс-фича, так что он всегда доступен.
Согласен с вами. Дополню ещё, что обработку 4хх ошибок приходится дополнительно пилить на клиенте, в отдельном обработчике «ошибок», которые не всегда ошибки, пока не заглянешь внутрь. Из-за этого возникает странный оверхэд по коду на пустом месте, потому-что кому-то захотелось поиспользовать HTTP-ответы везде, где это возможно.

А можно пример не совсем ошибки?

Да вот пожалуйста: юзер не найден, заказ не найден, платеж не найден, недостаточно доступа к какой-то части функции (403?) — можно менять аватар, но нельзя никнейм (нужно пояснять 403)

Немного поясню: юзер не найден, потому что такого юзера нет, либо этот юзер заблокирован, либо этот юзер из другой группы (например когда в REST указываешь сразу 2 параметра — ид сервера и Ид пользователя), или по точному совпадению никого не найдено, но вот вам в body возможные совпадения. Ну и конечно же, 404 когда просто дёргается неправильный url.

Для меня это всё обычные ошибки. Можно пояснять в теле, что не так или рекомендации какие-то давать. А когда неверный урл, то не то что обычная (пользователь ввёл что-то не то), а критическая или типа того — код неправильно написан.

Просто апи на то и апи, что должен поддерживать несколько разных клиентов, а у большинства из них дефолтное поведение — выдавать результат в виде ошибки, когда пришел ответ 4хх. Вот и приходится в них кодить обработку и 4хх и 200.

Это у какого большинства?

Выше правильно ответили. Но должен заметить, что REST никак не регламентирует такие вопросы, это семантика самого HTTP.

Хорошая статья, хочу больше.
Хотя совет "Избегайте частичных обновлений" на мой взгляд слишком категоричный. В реальном мире встречаются и другие причины поддерживать патч, кроме перечисленных. Например, забота о клиенте. Представьте, что вы должны каждый раз передать представление из 50 полей для того, что поменять одно-два (а остальные 48 полей в вашем конкретном сценарии вам не очень-то и интересны)

48 полей — это уже проблема само по себе, такие объекты надо декомпозировать.
Но вообще с т.з. разработчика клиента как раз удобнее все 48 посылать, чем выбирать изменившиеся.


Хорошая статья, хочу больше.

Дык собсно https://twirl.github.io/The-API-Book/docs/API.ru.html#chapter-11

NB: в этой книге часто используются короткие идентификаторы типа «123» в примерах — это для удобства чтения на маленьких экранах, повторять эту практику в реальном API не надо.

Начало шикарное. А в реальных системах легкость чтения не важна?

Вот несколько UUID попробуйте понять есть ли среди них одинаковые:
13eb9ffc-4e8d-11eb-ae93-0242ac130002
13eba470-4e8d-11eb-ae93-0242ac130002
13eba2a4-4e8d-11eb-ae93-0242ac130002
13eba480-4e8d-11eb-ae93-0242ac130002
13eba470-4e8d-11eb-ae93-0242ac130002
13eba538-4e8d-11eb-ae93-0242ac130002

А теперь предствьте что надо месяцами и годами смотреть в базу где все сущности так идентифицируются.

Неперебираемые идентификторы нужны только там где потенциально возможен перебор. И даже в этих местах надо оставлять обычный чиловой id и рядом генерить что-то неперебираемое для апи. Тогда и в БД смотреть будет удобно и от перебора зищитимся.

Тут вопрос в том нужно ли вообще в вашей базе смотреть на много обьектов сразу? Допустим каждая запись это уникальный заказ или что-то в этом духе. Тогда вам достаточно знать что у нее уникальный uuid и это гарантируется индексом. А смотреть на несколько сразу вам все равно не интересно т.к. одна операция выполняется только с одним заказом. В таком случае иметь несколько ид явно плохая идея т.к. появляется возможность ошибиться и например сгенерить для двух разных uuid одинаковые числовые ид.

Опыт эксплуатации разных систем говорит о том что в данные смотреть иногда нужно. С данными всякое непонятное бывает. И приходится лезть в таблички смотреть что там.

А смотреть на несколько сразу вам все равно не интересно т.к. одна операция выполняется только с одним заказом.

Отчеты самые разнообразные. Сверки любые. Обновления массовые в конце концов. Всегда и везде есть массовые операции.

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

числовое — PK
uuid — генерировать встроенной в бд функцией при инсерте.

Ошибиться везде можно, но в таком сценарии очень сложно.

В последнее время я склоняютсь к тому что uuid и подобное вообще не нужно. Случайного лонга хватает для любых практических задач. И человекочитаемость резко повышается. Рейт лимитер на все места публично апи нужен обязательно в любом случае.

Чем случайный long (знаковый?) лучше uuid?

Пусть будет диапазон (1, ulong64 / 2 — 1) для однозначности. Везде удобно и везде влезет.

Да, лучше чем uuid. Вероятность коллизий мизерная на практике. Перебрать при любом разумном рейт лимитере невозможно. И смотреть глазами на него удобно.
Одни плюсы.

Вы хотели сказать (0, 2^53 — 1) чтобы влезал в JS и прочие языки и платформы, где и целых-то толком нет?

0 я бы исключил, но в общем да. Мы же апи делаем для всех. И не хотим чтобы клиенты страдали просто так.
Вот несколько UUID попробуйте понять есть ли среди них одинаковые:

Во-первых, необходимо использовать рандомные идентификаторы, похожих не будет.
Во-вторых, решительно не понимаю, в чем преимущество числовых идентификаторов. Они удобны, пока их мало. Когда счет на миллионы-миллиарды идёт — точно так же поди разбери, в каком знаке отличие.

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

Я взял uuid сгенеренные по RFC. Любая хорошая генерирующая функция вам такие же даст. При массовых вставках. Писать самому такие вещи это путь к ошибкам.

Во-вторых, решительно не понимаю, в чем преимущество числовых идентификаторов. Они удобны, пока их мало. Когда счет на миллионы-миллиарды идёт — точно так же поди разбери, в каком знаке отличие.

Нет же.
Цифровые отлично сортируются понятным для человека образом, и отлично сравниваются на глаз.
Вот десяток несортированных и достаточно больших
108429824
516235466
671120218
719027734
240635993
161055999
494179034
180975157
105039137
945926472


А вот они же сортированные
105039137
108429824
161055999
180975157
240635993
494179034
516235466
671120218
719027734
945926472


Согласитесь гораздо понятнее чем я выше пример с уидами приводил. С уидами сортировка не помогает сделать понятнее.
Я взял uuid сгенеренные по RFC.

Согласно какому RFC, если не секрет?

Согласно какому RFC, если не секрет?

rfc4122
Версия 1. Она чаще встречается на практике.

Когда их становится много, это уже не важно. Глаз замыливается.
В табличке ключ + несколько ссылок на соседние табличке. И уже даже на экран не влазит. А числа отлично влазят и не мельтешат.

Не очень понимаю, что вы этим хотели сказать.


Хороший тон при разработке API — использовать для идентификаторов сущностей глобально уникальные строки, либо семантичные (например, "lungo" для видов напитков), либо случайные (например UUID-4). Это может чрезвычайно пригодиться, если вдруг придётся объединять данные из нескольких источников под одним идентификатором.
Отличать становится проще. А читаемости это не добавляет.
Я выше привел пример несложной таблички ключ + допустим 4 ссылки на другие таблички. Это не лезет ни на один экран. Это порождает визуальный шум. Колонки в любом просмотрщике начинают разъежаться.

И самое главное вы со мной полностью согласны:
в этой книге часто используются короткие идентификаторы типа «123» в примерах — это для удобства чтения на маленьких экранах, повторять эту практику в реальном API не надо.

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

Хинт: если взять последние, ну скажем 6 знаков uuid-а — получится ровно то же самое длинное число. Админки, которые я видел, именно так и делали — последние n знаков показывали, полный uuid за спойлером.

Хорошо когда админка есть, работает и там есть то что нужно…

Мы разработчики и все немного девопсы. Консоль, grep, less, mysql-client, vi. Часто приходится обходится инструментами работаюшиеми всегда и везде.

Я, если честно, устал спорить с утверждением «10 десятичных цифр лучше чем 32 шестнадцатеричные». Окей, можете форкнуть репозиторий и исправить в своей копии.

Ключевое даже не 10 десятичных.
А использование обычных десятичных чисел по порядку везде где перебор невозможен и где из них нельзя извлечь какую-либо информацию неполучаемую другими путями. В среднем не очень большие цифры будут. Таких мест большинство в среднем приложении. В энтерпрайзе работающем внутри корпоративной сети никакой защиты в этих местах вообще надо.

Обычные числовые PK. Они же id для всего что клиенту отдаем.
А вся защита только в тех местах где она нужна. Как ее делать обсуждаемо на самом деле. С учетом что таких мест не очень много можно и смириться с неудобствами в них.

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

Обычная sql база. Она всегда внутри любой большой системы сидит.
Без костылей, атомарно, с гарантиями. Все как мы любим.

Внутри большой системы обычно несколько баз, и не только sql.


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

sql там есть всегда. Ее и используем как генератор id.
Не общий. У каждой сущности свой в своей табличке, там же и саму сущность сохранить можно.
Можно хоть кластер пер тейбл заводить, если за производительность боитесь.

Гарантии это классно. Надо пользоваться. У новых модных систем с ними всегда не очень.

Есть сущности из нескольких табличек, типа документ с метаданными и табличной частью бьётся на таблички 1:N. С автоид сложно создать его атомарно одним запросом с клиента: сначала надо вставить метаданные в сторонй 1, получить их ид, а потом вставлять строки стороны N с этим id. Ну и необходимость синхронщины вылазит.

Логически связанные таблички придется делать в одной БД. И тогда все атомарно. Транзакции это классно. И это же поможет атомарные обновления делать. Вин-вин. И никаких распределенных транзакций. Маштабируемся чтением со слейвов, на край шардированием. Далеко не везде нельзя жить без данных за последние секунды.

При проектировании систем думать надо. Надо делать хорошо, не надо делать плохо. Если сделал плохо надо переделывать.

А зачем сортировать случайные числа?

Это пример некоего набора id в которых мы хотим что-то понять. Одинаковость, чтобы понять должно ли оно джойнится. Просто что там есть чтобы сравнить с тем что в логах нагрепали. Сами придумайте зачем вы смотрите на срез данных из прода. Причин достаточно на самом деле.

Это пример насколько удобнее смотреть на числовые id.
Так uuid и есть, по сути, просто определенным способом сгенерированное 128-битное число. Ничего вам не мешает для удобства его отобразить как число в десятичной записи и будет то же самое.
Есть стандарты против которых не попрешь. Отображение uuid из таких. Они хороши для своих случаев.
А вот для случая когда можно сделать одну точку генерации (запись в БД например), то есть варинаты удобнее. Подсокращенный случайный лонг, например.
UFO just landed and posted this here
Независимые инстансы БД могут быть только в одном случае. Это шарды. Обычно типовые hash(userId)%N Слияние может быть нетривиально по разным причинам, но как делать понятно.

Все остальное это как правило ошибка проектирования. И надо не костыли ставить, а исправлять эту ошибку.

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

Переименовываем инстансы в шарды.
Обучаем приложеньку работать с несколькими шардами.
МВП готов. Релизимся.
Обучаем жить нескольких клиентов в одном шарде.
Придумываем и делаем для всех новых нормальную схему шардирования.
Старых переселяем в отдельные схемы, вместо отдельных инстансов и пусть живут как жили. Схем в БД что-ли жалко?

Когда-нибудь потом когда будут проблемы придумываем систему решардирования и для новых и для старых. И решардируем все. Это будет через годы, а то и никогда.

А с админами, хелпдесками и прочими, кому нужен доступ ко всем шардам одновремено для задач типа позвонил пользователь и просит удалить его аккаунт, но сказать на каком он шарде не может.

Тикет на разработку: «Сделать адмнику с возможностью работы со всеми шардами»
С учетом что это админка с никакой нагрузкой и понимающими пользователями можно делать очень неоптимально и не очень красиво.
Выйдет сделать достаточно быстро.
UFO just landed and posted this here
Зачем его дропать? Вот чем вам мешает вторая схема в БД? У вас шардирование по географическому принципу. Я допускаю что подумав вы решили что оно неоптимально. Если это неоптимально начало стоить много денег надо просто перешардировать по другому признаку.

У вас кажется до «такой вариант шардирования слишком дорог и можно съекономить минимум сотню серваков» далеко еще. Так пусть живет. Никому же не мешает.

Например, участились случаи двойных регистраций пользователей и это создаёт проблемы репутации. Или регулятор потребовал что у одного юрлица должнен быть только один договор на обслуживание с одним физлицом

Например, участились случаи двойных регистраций пользователей и это создаёт проблемы репутации.

Вы вот это серьезно? В мире где сотовый номер стоит рублей 30, а паспортные данные настолько похожие на правду что вы их не проверите рублей 500?

Если у вас Банк или что-то подобное зарегулированное с правом проверки личности, то это делается другими способами. И опять таки с базами и шардированием не связанно никак.

Или регулятор потребовал что у одного юрлица должнен быть только один договор на обслуживание с одним физлицом

Юридические тонкости с техническими решениями не связанны вообще никак.
Отправить к регулятору юристов и пусть разбираются. В худшем случае какую плашку вас заставят повесить или галочку при регистрации добавить.

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


А шардирование же вы притащили в тред, нет? Задача была озвучена как слить базы.


Ещё как связаны, особенно с ПДн в последнее время.

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

SSO вроде давно придумали. Зачем вы вообще делаете регистрацию вместо кнопки войти через «Тут все подряд исходя из региональной специфики»?

А шардирование же вы притащили в тред, нет? Задача была озвучена как слить базы.

Озвучить можно много разных задач. Это не означает что их следует делать. Часто есть более правильные и хорошие решения, чем делать что-то неправильно сформулированное с неясной целью.

Бизнес пришел с задачей: Мы тут 5 лет назад сделали региональные серваки, а теперь поняли что надо чтобы пользователи с них друг с другом взаимодействовать могли.
Бизнес совсем не хочет слияния баз. Он хочет чтобы пользователи могли взаимодейстовать. И надо подумать как это нормально сделать. В среднем решение сливать базы это худший выбор.

Ещё как связаны, особенно с ПДн в последнее время.

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

Если вы опять таки Банк или кто-то еще кому надо. То такое делается отдельно от всего. Все подсистемы, кроме подсистемы валидации человека, никогда не должны видеть его номер паспорта или пароль. Они просто должны получать ответ — Да это он, Нет это не он.

Проверяющая человека подсистема пишется отдельно, по своим правилам и очень аккуратно.
Тогда и утечек не будет, и о безопасности говорить можно. Если у вас все равномерно везде, то утечка это только вопрос времени.
Зачем вы вообще делаете регистрацию вместо кнопки войти через «Тут все подряд исходя из региональной специфики»?

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


Бизнес совсем не хочет слияния баз.

Он хочет именно единую базу — явно озвученное желание. Да, можно в UI/API сделать видимость единой базы, чтоб регион был лишь виртуальным или может даже реальным полем юзера, но непонятно зачем, тем более части проблем это всё равно не решит без существенной переработки основной кодовой базы, чтобы обеспечивала, например, уникальность между двумя идентичными таблицами в соседних схемах.


Вам персональные данные не нужны.

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

Вы уже вовсю сову натягивать начали.
На маштабных проектах есть и люди и силы все сделать нормально. Такие маштабные рефакторинги с бухты барахты не делаются. И их скорость вот вообще не зависит от типа айдишников. Там столько других проблем что это такая мелочь.

И задачи людям выше джуна так не ставятся. Такие решения это результат договоренностей команды. Вас специально наняли чтобы вы принимали технические решения. Любые технические решения.

И даже данные которые надо охранять с остальными не мешают. Просто ради того чтобы не было утечек и чтобы спокойно большую часть кода писать. Не нарываясь на пустом месте.

У вас все сферическое в вакууме. На практике так не бывает.
UFO just landed and posted this here
Для пустых результатов поиска часто используют 204 No Data. Это как 404, но без ошибки)
Ну и насчёт запрета null это вы зря. Если программист клиента не может отличить null от false, ну так может гнать такого из профессии? А то у вас какой-то детский сад получается, null есть, а слова такого нет.
Для пустых результатов поиска часто используют 204 No Data. Это как 404, но без ошибки)

204 подразумевает пустое тело ответа — а значит, ничего полезного (например, предложение исправить опечатку) в нём не передать. Плюс пустое тело — невалидный json, клиентам придётся обрабатывать его отдельно.


Если программист клиента не может отличить null от false, ну так может гнать такого из профессии?

Если разработчик API предлагает отличать null от false, может его нужно гнать из профессии?
Популярным API чисто статистически будут пользоваться тысячи, может десятки тысяч разработчиков. Они будут допускать ошибки, а результатом этих ошибок будут проблемы реальных людей. Сознательно провоцировать ошибки, мол, нечего джунов нанимать — не очень конструктивная позиция.

Конструктивно использовать нормальные языки типа TypeScript/Scala3/Kotlin в которых нет проблем с null / false, и другие бывают протоколы связи, тот же GraphQL, в котором тоже есть различие между null/false.


Но если вы конечно настаиваете на кактусе js/json, то ваша воля

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

Не зависимо от клиента вы можете либо нормальный api, либо убогий api сделать.


В связи с этим, для вас же важно различать понятия


  1. Булево
  2. Наличие или отсутствие значения

Вот JavaScript проектировали му*аки, придумали null, undefined
И ещё хуже сделали конструкцию if, которая не различает null, undefined, false, 0… (типа хотели как лучше)


Свободы вы выборе технологий недостижимо, например я захочу на brainfuck/asm/t-sql использовать ваш api, тогда как со свободой выбора?


Дело не в личных желаниях, а в объективной данности

Ну и не могу не отметить, что поле, принимающее три значения — true, false и null — это какой-то кадавр, независимо от наличия в языке удобных конструкций для работы с такой псевдотроичной логикой.

Кадавр — это если ещё undefined )

Слушайте, я вас лет 15-20 (виртуально) знаю, поэтому отвечу культурно.
Даже если мы берём элемент управления «чекбокс», почти во всех ОС у него есть «третье состояние» — когда ответ пользователя неизвестен.
И если вебмакака не может передать это третье состояние от сервера интерфейсу — ну…

Так я и пишу, что надо разрабатывать API так, чтобы у вебмакаки не было этой проблемы. Указывать дефолтное состояние чекбокса то бишь. И руки оторвать тому, кто придумал неинициализированное состояние системного чекбокса.

За что? Удобно же. Например, если нам нужен обязательный ответ на то согласен юзер на спам )) или нет

Далеко не всегда можно инициализировать чекбокс по умолчанию.
Можно привести кучу примеров, полностью зависимых от конечного пользователя (скажем пол/раса/ориентация/вероисповедание по умолчанию могут вовсе задеть чувства и стать причиной исков).


Все же, null/optional, выглядят вполне оправданно в определенных моментах.
Это, как мне кажется, также может быть куда прозрачнее, чем связь с дополнительным полем.


А за статью спасибо :)

Так вот чтобы никого не оскорблять, должен быть явный пункт «предпочту не говорить» вместо неявного null.

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


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

Если разработчик API предлагает отличать null от false, может его нужно гнать из профессии?

Ну это вы вот прямо зря. Погуглите про реляционную алгребру, там это немного используется.
С пустым, но валидным, ответом работать клиенту гораздо удобнее.
Весь код становится чище и однозначнее. Ответ сервера 2xx и ответ успешно десериализовался.
Значит запрос корректный, сервер ответил корректно, ошибок нигде нет. Смело обрабатываем ответ зная что все остальное точно хорошо.
Ошибки идут отдельно. Любой недесериализовавшийся ответ рассматриваем ошибкой.

Любое изменение в этом месте делает больно клиенту. Появляются странные ветки в обработчике ответа. Когда все хорошо, но ответ сервера не десериализуется. И надо это корректно обработать.
Вариант 2: разработать формат описания атомарных изменений.

Всё уже украдено разработано до нас: JSON PATCH http://jsonpatch.com/ RFC 6902,

Ну как «разработано». Операции «сдвинь элемент массива на n позиций влево» там нет, например. Если б любая предметная логика описывалась просто правкой JSON-ов, я бы давно помер с голода.

Так может слать с клиента на сервер тьюринг-полный байт-код, чтоб он исполнялся там?


Пост в целом в контексте REST воспринимеатся, а это оперирование представлениями, а не RPC

Так ровно это REST и предполагает ;) Принцип code-on-demand.
Следующая глава будет про интерфейсы, а вот через неделю планирую взяться за главу ‘Deconstructing the REST myth’

О мои глаза! Зачем я это прочёл?
Молодые люди, именуйте свои статьи не для себя, а для других. Пожалуйста!

Да, я понимаю, что это брюзжание:

А где API-то (API: ru.wikipedia.org/wiki/API )?
О чём вообще приведённые в статье принципы?
Учтите, пожалуйста, поиск по статье слова 'web' не даёт ни одного совпадения! Т.е. это как-бы статья не об (не только об) web-е.

— Используем глобальные идентификаторы?: откроем файл по имени и некоторому guid-у?

— Клиент должен знать состояние системы?: мальчик/девочка, у тебя нет прав чтобы знать полное состояние системы! Даже сама система не знает полного состояния системы. Хотя, технически, можно снять дамп со всех процессов/памяти и др.

— Избегайте не-атомарных операций? Понятно, почему всё так тормозит! Вы бы ещё предложили залочить весь сервер пока обрабатывается каждый запрос! Ну так, на всякий случай.

Чёрт, как же народ-то при разработке POSIX, WinAPI не додумался до уникальных идентификаторов? Вот почему, оказывается, все винду ломают! Не потому, что драйвера не в тех кольцах, или буфера переполняются… а потому что идентификаторов нет.

Ну, и теперь можете накидывать минусов…

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

Апломб? Возможно. Прошу прощения за излишнюю эмоциональность.
Дилетант? Тоже возможно. В том, что Вы описываете — однозначно.
Критика? Да.
Критика чего? Названия статьи!
Попробуйте хотя бы себе ответить: то что Вы написали — это API? Не протокол, формат или др. Именно API?

Последний абзац прочитайте, пожалуйста.

Я прочитал последний абзац. И по ссылке в статье нашёл, что есть API с Вашей точки зрения. И даже оценил изящный переход к JSON-over-HTTP-эндпойтов.

Ну что сказать? Ок, это Ваша статья и и Ваши определения.
Тогда удачи Вам в таком нелёгком деле как написание книги.

Половина из пунктов в статье имеют opinionated и продуманные решения в GraphQL. Так что я бы сказал, что советы наполовину про REST API (со всеми вытекающими ограничениями), а не просто про API.

Какие именно советы специфичны для REST и почему?

Очень много про передачу представлений состояний) Почти ничего про операции, отличные от HTTP методов.

Состояние в "Representational state" означает состояние, в которое переходит приложение после выбора гиперссылки, и это состояние (равно как и его дальнейшие переходы) определяется представлением ресурса. Тот самый HATEOAS.


The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_1


REST concentrates all of the control state into the representations received in response to interactions. [...] For a browser application, this state corresponds to a "web page," including the primary representation and ancillary representations, such as in-line images, embedded applets, and style sheets.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_3

Ну вот как я понимаю, из-за советов типа Клиент всегда должен знать полное состояние системы пост и воспринимается в контексте REST

Честно говоря, я не понимаю, что значит знать полное состояние системы ;)

А можно примеры продуманных решений в GraphQL? Единственное, что он умеет из списка — возвращать пустые массивы без ошибки.

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

UFO just landed and posted this here
Sign up to leave a comment.

Articles