данные, которые в REST должны быть подмножеством полей ресурса.
Нет в REST (rest api, если быть точным) такого ограничения. От куда всего его выдумывают? Передавайте что хотите. Тут исключительно вопрос удобства реализации, тестирования, документирования и поддержки всего этого дела. В общем случае просто получается удобнее, если то что возвращает GET можно потом отправить в PATCH. И фреймворки писать удобнее, когда у нас есть супер жёсткие ограничения. Можно тогда свести весь код приложения к минимуму - указал фреймворку на таблицу в базе данных, а остальное он всё сам сделает.
Не такой и специфичный. Он, если не ошибаюсь, даже описан в спеке на HTTP. Там так и сказано про 404, что сервер может возвращать его по любой причине из-за которой нельзя дать понять клиенту, что указанный в URL ресурс существует на сервере. Как пример - отсутствие у клиента прав доступа к ресурсу для которого один факт его наличия на сервере раскрывает приватную информацию. Например если ID ресурса - это любой, публично известный идентификатор человека.
А возвращать 401/403 на любой чих - это, по моему, довольно таки довольно специфичное решение, которое не всегда удобно. Чаще всё таки нет проблем, с тем, что бы клиент без прав доступа узнал, что ресурс на который он стучится - отсутствует.
При этом также должен меняться статус статьи, которая является другим ресурсом, а это не соответствует принципам REST.
В REST нет такого, там как раз максимально всё говорит о том, что клиент не должен рассчитывать на какое-то состояние на сервере. Это состояние может измениться там в любое время и по любой причине. Сам сервер может изменить что-то по крон-таске, а может прийти запрос от другого клиента и внести изменения. Нет никакого запрета на то, что бы приложение на сервере изменило другие сущности в процессе создания/изменения сущности, которую попросил изменить клиент в текущем запросе.
Не вижу разницы в сложности межу тем, что бы создать 20 уникальных глаголов для двух сущностей, или создать 10 сущностей с 4-мя универсальными глаголами. Уровень сложности на бекенде в общем случае получится тот же самый. Но второй вариант, за счёт унификации интерфейса и использования функционала хорошо документированного протокола HTTP, позволяет быстрее в нём разобраться тем, кто знает про HTTP, но в первый раз видит ваш API. А это очень важный показатель. Никто ведь не берёт первого попавшегося C++ разработчика, на проект написанный на питоне. И в первую очередь, при прочих равных, предпочтение будут отдавать тем кандидатам, которые знакомы с технологиями и принципами, которые используются в проекте. В этом контексте использование широкоизвестных и документированных технологий и протоколов облегчит поддержку проекта, в отличии от чего-то самописного, которое, как часто бывает, ещё и не описано в документации.
если бизнес использует не существительное "Публикация", а глагол "Опубликовать"
А вас не соответствие бизнес-глаголов с сущностями смущает только на уровне API? На уровне базы данных вас не коробит, что там по сути только одни сущности, и ни один глагол не совпадает с тем, что написано в бизнес-требованиях?
По идее, get запрос предназначен что бы получить состояние ресурса на который указывает url, например /users. Получение в этом же ответе списка состояний дочерних ресурос (/users/<user_id>) - это уже доп.функционал, который не обязательно реализовывать в рамках get запроса к ресурсу-контейнеру. Если ваши запросы простые, быстро выполняются, тогда можно использовать get к контейнеру. Если же у вас это что-то сложное, с достаточной вероятностью непредсказуемо долгого времени выполнения, то лучше под это предусмотреть отдельное api. Такое как выше описали - отдельный ресрус "поисковые_запросы", который будет через post создавать ресурсы "запрос", в котором будут возвращаться результаты поиска. При этом не обязательно этот "запрос" сохранять в базу данных, если это не требуется на первых порах. Главное что, api уже поддерживает такую возможность, и в будущем, при усложнении поиска, можно будет реализовать полностью "асинхронную" схему работы поиска не меняя api.
DELETE относится исключительно к тому ресусрсу, на который указывает url. Параметры запроса, где бы они не были переданы, не имеют отношения к тому что именно надо удалить. Они могут как-то, менять процесс удаления или вообще его отменить, но не выбрать что именно надо удалить. Если надо удалить пачку разных ресурсов, то такое корректее реализовать методом POST к специальному ресурсу, который можно назвать, например, "items_deleter". Такой подход будет особенно полезен в тех случаях, когда удаление 100500 ресурсов выполняется долгое время. В этом случае лучше работать по схеме "быстро создать задачу и пускай сервер её выполняет где-то в фоне".
"Избыточная" вложеность может быть оправдана по разным причинам. Например при использовании шардированной базы данных надо знать item_id, даже если subitem_id глобально уникален. Иначе запрос к базе, без указания фильтра по ключу шардирования, полетит на все шарды и будет создавать не нужную нагрузку.
То что имя создваемого клиентом ресурса оказалось не допустимо по любой причине (в том числе и запрет на дубли) - это ошибка клиента, т.к. это он передал это имя в теле запроса. Значит статус ответа должен быть из группы 4хх. Из имеющихся вариантов больше всего подходит 422 - ошибка валидации входных данных, т.к. проверка на дубликат - это точно такая же валидация, как и проверка на длину строки, вхождение числа в разрешённый интервал или проверка значения на вхождение в список допустимых. При необходимости в теле с ошибкой можно указать ссылку на существущий ресурс, который "мешает" создать дубликат.
Есть конечно доп. возможность - вернуть код 200, вместо 201, и в теле ответа передать уже существующий в системе ресурс. А через заголовок Location - ссылку на этот ресурс. Можно даже применить к существующему ресурсу значения остальных полей, переданных в запросе. Это всё зависит от бизнес логики. Если клиенту абсолютно плевать на то, что на сервере есть дубликат, и он любыми средствами будет добиваться изменения состояния на сервере, то можно оптимизировать этот процесс. Не заставлять клиент получать ошибку от POST метода и потом вызывать PATCH метод, а сразу в POST выполнить нужные изменения и сообщить об этом кодом 200, намекая, что этот запрос не создал новый ресурс.
И в этой статье какое-то произвольное манипулирование исходными условиями. Почему-то создавать новые "рога" можно "неограниченно". А петля с чего-то вдруг обязательно должна коснуться поверхности сферы, как будто у нас куда-то пропала возможность бесконечно делить любое пространство на более мелкие, но тем не менее не пустые пространства. И видимо у обсуждаемой петли есть толщина, из-за которой мы не сможем протолкнуть её через некую, бесконечно далёкую пару "рогов".
Я не специалист в топологии, но очень странно в её контексте выглядят в этой статье обсуждения расстояний и их соотношение. Какое это имеет значение? Как захотели так и растянули кривую/поверхность/область. Конкретные величины расстояний и их взаимное отношение не имеют значения, главное что бы выполнялись ограничения накладываемые на трансформации.
А вот если бы у нас была сфера, вместо плоскости. Тогда указанное утверждение можно считать верным. Любая петля на сфере делила бы её поверхность на две одинаково устроенные области.
Внешняя область имеет отверстие, образованное областью С, поэтому она уже отличается по своим свойствам от С. Тем не менее она, по моему, односвязная, т.к. любые две точки этой области можно соединить непрерывной кривой, которая не пересекает границы области.
Какой-то странный контрпример (или его описание в этой статье). Мы не можем стянуть петлю в точку потому что: "Ааааа, вы только поглядите какой сложный и страшный рисунок! Зуб даю, что нельзя петлю стянуть!". Апелляция к бесконечности выглядит как какой-то шарлатанский трюк.
Исправьте ваш собственный рисунок "рогов" от руки. Он не соответствует вашему описанию и тем более не соответствует дальнейшим изображениям "рогатой" сферы. У вас красные рога не скрещиваются с зелёными "замком". Они просто находятся перед ними.
Интересно, почему изначально была выбрана MongoDB, если у неё, по сути, есть только один достаточно существенный плюс - это простое шардирование из коробки? Но, как указано в статье, никто в самом начале даже не думал про шардирование.
Я конечно понимаю, что вероятно в приведённом коде практически нечего оптимизировать, но можно же было, хотя бы для порядка, собирать релизную версию бинарного файа, а не отладочную.
Дааа-с, завернуть в gather() отправку запросов на сервер вы догадались, а сделать то же самое с получением тела ответа от сервера - нет. В результате ответы на свои запросы вы по прежнему вычитываете последовательно, один за другим.
А на что вы намекаете, говоря, что на С точно так же можно написать? Типа зачем тогда нужен Rust?
Написание программ состоит не только из написания списков. То что оптимальная (по скорости) реализация списков в Rust, посути копирует реализацию из C, не означает, что Rust безполезен и в нём в принципе нельзя писать быстрый код без сырых указателей, unsafe и обхода borrow-чекера.
Нет в REST (rest api, если быть точным) такого ограничения. От куда всего его выдумывают?
Передавайте что хотите. Тут исключительно вопрос удобства реализации, тестирования, документирования и поддержки всего этого дела.
В общем случае просто получается удобнее, если то что возвращает GET можно потом отправить в PATCH.
И фреймворки писать удобнее, когда у нас есть супер жёсткие ограничения. Можно тогда свести весь код приложения к минимуму - указал фреймворку на таблицу в базе данных, а остальное он всё сам сделает.
Не такой и специфичный. Он, если не ошибаюсь, даже описан в спеке на HTTP. Там так и сказано про 404, что сервер может возвращать его по любой причине из-за которой нельзя дать понять клиенту, что указанный в URL ресурс существует на сервере. Как пример - отсутствие у клиента прав доступа к ресурсу для которого один факт его наличия на сервере раскрывает приватную информацию. Например если ID ресурса - это любой, публично известный идентификатор человека.
А возвращать 401/403 на любой чих - это, по моему, довольно таки довольно специфичное решение, которое не всегда удобно. Чаще всё таки нет проблем, с тем, что бы клиент без прав доступа узнал, что ресурс на который он стучится - отсутствует.
В REST нет такого, там как раз максимально всё говорит о том, что клиент не должен рассчитывать на какое-то состояние на сервере. Это состояние может измениться там в любое время и по любой причине. Сам сервер может изменить что-то по крон-таске, а может прийти запрос от другого клиента и внести изменения.
Нет никакого запрета на то, что бы приложение на сервере изменило другие сущности в процессе создания/изменения сущности, которую попросил изменить клиент в текущем запросе.
Не вижу разницы в сложности межу тем, что бы создать 20 уникальных глаголов для двух сущностей, или создать 10 сущностей с 4-мя универсальными глаголами. Уровень сложности на бекенде в общем случае получится тот же самый.
Но второй вариант, за счёт унификации интерфейса и использования функционала хорошо документированного протокола HTTP, позволяет быстрее в нём разобраться тем, кто знает про HTTP, но в первый раз видит ваш API. А это очень важный показатель. Никто ведь не берёт первого попавшегося C++ разработчика, на проект написанный на питоне. И в первую очередь, при прочих равных, предпочтение будут отдавать тем кандидатам, которые знакомы с технологиями и принципами, которые используются в проекте. В этом контексте использование широкоизвестных и документированных технологий и протоколов облегчит поддержку проекта, в отличии от чего-то самописного, которое, как часто бывает, ещё и не описано в документации.
А вас не соответствие бизнес-глаголов с сущностями смущает только на уровне API? На уровне базы данных вас не коробит, что там по сути только одни сущности, и ни один глагол не совпадает с тем, что написано в бизнес-требованиях?
По идее, get запрос предназначен что бы получить состояние ресурса на который указывает url, например /users. Получение в этом же ответе списка состояний дочерних ресурос (/users/<user_id>) - это уже доп.функционал, который не обязательно реализовывать в рамках get запроса к ресурсу-контейнеру.
Если ваши запросы простые, быстро выполняются, тогда можно использовать get к контейнеру. Если же у вас это что-то сложное, с достаточной вероятностью непредсказуемо долгого времени выполнения, то лучше под это предусмотреть отдельное api. Такое как выше описали - отдельный ресрус "поисковые_запросы", который будет через post создавать ресурсы "запрос", в котором будут возвращаться результаты поиска. При этом не обязательно этот "запрос" сохранять в базу данных, если это не требуется на первых порах. Главное что, api уже поддерживает такую возможность, и в будущем, при усложнении поиска, можно будет реализовать полностью "асинхронную" схему работы поиска не меняя api.
DELETE относится исключительно к тому ресусрсу, на который указывает url. Параметры запроса, где бы они не были переданы, не имеют отношения к тому что именно надо удалить. Они могут как-то, менять процесс удаления или вообще его отменить, но не выбрать что именно надо удалить.
Если надо удалить пачку разных ресурсов, то такое корректее реализовать методом POST к специальному ресурсу, который можно назвать, например, "items_deleter".
Такой подход будет особенно полезен в тех случаях, когда удаление 100500 ресурсов выполняется долгое время. В этом случае лучше работать по схеме "быстро создать задачу и пускай сервер её выполняет где-то в фоне".
"Избыточная" вложеность может быть оправдана по разным причинам.
Например при использовании шардированной базы данных надо знать item_id, даже если subitem_id глобально уникален. Иначе запрос к базе, без указания фильтра по ключу шардирования, полетит на все шарды и будет создавать не нужную нагрузку.
То что имя создваемого клиентом ресурса оказалось не допустимо по любой причине (в том числе и запрет на дубли) - это ошибка клиента, т.к. это он передал это имя в теле запроса. Значит статус ответа должен быть из группы 4хх.
Из имеющихся вариантов больше всего подходит 422 - ошибка валидации входных данных, т.к. проверка на дубликат - это точно такая же валидация, как и проверка на длину строки, вхождение числа в разрешённый интервал или проверка значения на вхождение в список допустимых. При необходимости в теле с ошибкой можно указать ссылку на существущий ресурс, который "мешает" создать дубликат.
Есть конечно доп. возможность - вернуть код 200, вместо 201, и в теле ответа передать уже существующий в системе ресурс. А через заголовок Location - ссылку на этот ресурс. Можно даже применить к существующему ресурсу значения остальных полей, переданных в запросе. Это всё зависит от бизнес логики. Если клиенту абсолютно плевать на то, что на сервере есть дубликат, и он любыми средствами будет добиваться изменения состояния на сервере, то можно оптимизировать этот процесс. Не заставлять клиент получать ошибку от POST метода и потом вызывать PATCH метод, а сразу в POST выполнить нужные изменения и сообщить об этом кодом 200, намекая, что этот запрос не создал новый ресурс.
Как работает автомат?
Очень просто. Тра-та-та, и вы убиты.
Почему линии в тексте называются "строками"? Это какой-то кривой перевод слова lines?
А как устроено голосование за пиксели? У них есть предвыборная программа, дебаты? При голосовании используется ДЭГ или другая система?
И в этой статье какое-то произвольное манипулирование исходными условиями. Почему-то создавать новые "рога" можно "неограниченно". А петля с чего-то вдруг обязательно должна коснуться поверхности сферы, как будто у нас куда-то пропала возможность бесконечно делить любое пространство на более мелкие, но тем не менее не пустые пространства. И видимо у обсуждаемой петли есть толщина, из-за которой мы не сможем протолкнуть её через некую, бесконечно далёкую пару "рогов".
Я не специалист в топологии, но очень странно в её контексте выглядят в этой статье обсуждения расстояний и их соотношение. Какое это имеет значение? Как захотели так и растянули кривую/поверхность/область. Конкретные величины расстояний и их взаимное отношение не имеют значения, главное что бы выполнялись ограничения накладываемые на трансформации.
А вот если бы у нас была сфера, вместо плоскости. Тогда указанное утверждение можно считать верным. Любая петля на сфере делила бы её поверхность на две одинаково устроенные области.
Внешняя область имеет отверстие, образованное областью С, поэтому она уже отличается по своим свойствам от С. Тем не менее она, по моему, односвязная, т.к. любые две точки этой области можно соединить непрерывной кривой, которая не пересекает границы области.
Какой-то странный контрпример (или его описание в этой статье). Мы не можем стянуть петлю в точку потому что: "Ааааа, вы только поглядите какой сложный и страшный рисунок! Зуб даю, что нельзя петлю стянуть!".
Апелляция к бесконечности выглядит как какой-то шарлатанский трюк.
Исправьте ваш собственный рисунок "рогов" от руки. Он не соответствует вашему описанию и тем более не соответствует дальнейшим изображениям "рогатой" сферы. У вас красные рога не скрещиваются с зелёными "замком". Они просто находятся перед ними.
Думаю что этот текст был сгенерирован чем-то вроде СhatGPT.
Интересно, почему изначально была выбрана MongoDB, если у неё, по сути, есть только один достаточно существенный плюс - это простое шардирование из коробки? Но, как указано в статье, никто в самом начале даже не думал про шардирование.
Я конечно понимаю, что вероятно в приведённом коде практически нечего оптимизировать, но можно же было, хотя бы для порядка, собирать релизную версию бинарного файа, а не отладочную.
Дааа-с, завернуть в gather() отправку запросов на сервер вы догадались, а сделать то же самое с получением тела ответа от сервера - нет. В результате ответы на свои запросы вы по прежнему вычитываете последовательно, один за другим.
А на что вы намекаете, говоря, что на С точно так же можно написать? Типа зачем тогда нужен Rust?
Написание программ состоит не только из написания списков. То что оптимальная (по скорости) реализация списков в Rust, посути копирует реализацию из C, не означает, что Rust безполезен и в нём в принципе нельзя писать быстрый код без сырых указателей, unsafe и обхода borrow-чекера.