Если вы делаете это не для себя — лучше спросите тех кто будет пользоваться, как им логичнее.
И, как я уже написал чуть раньше — если изменение состояния не предполагает отдачу свойственного только ему данных, всё же как-то логичнее не делать отдельный ресурс, но… это ваш API.
То что написано в статье — одно из мнений. Делайте так как вам подсказывает команда, здравый смысл, клиенты и ТЗ.
REST — это не стандарт и не спецификация, никто вам не может указывать что "можно" а что "нельзя", хотя если пользователи станут возмущаться — к ним всё же стоит прислушаться, потому что вы делаете это для них.
Идеальный API — это тот когда пользователи активно его используют и при этом у них (почти) не возникает вопросов — исходите из этого.
Никто не запрещает действия при изменении свойства, этот ворох изменений может быть сделан во время PATCH при изменении состояния свойста, с соответствующим фидбеком (получилось/нет).
С другой стороны, точно также никто не запрещает создать отдельный ресурс для этого, который будет отличаться только… отдельным ресурсом, в то время как с точки зрения клиента принципиально ничего не меняется — объект активирован, что там произошло для этого "у ней внутре" его не интересует, кроме подтверждения изменения состояния.
Если же активация подразумевает отдачу чего-то очень интимного, свойственного только активации (credentials, token etc) — да, в этом случае уже будет логично создать отдельный ресурс.
POST — создать новый объект. PUT — заменить существующий объект. PATCH — изменить частьсуществующего объекта. Что тут неочевидно?
Если у объекта есть атрибут "активен" — это часть объекта, так что на любые изменения отдельных частей — это таки PATCH.
Если уж вам хочется что бы всё было отдельно — сделайте user-activation и используйте PUT или POST, хотя это (как мне кажется) менее логично, потому что сразу возникает искушение создать его отдельно от user (и кто-то обязательно это сделает, пусть и неудачно).
Вот спорно очень насчёт кодов ошибок. Потому как, к примеру, 404 — относится к тому что нет маршрута или нет документа? 50x — проблема с транспортом, прокси или самим приложением? Если не смотреть внутрь — то по одному коду непонятно, это проблема endpoint или самого приложения, а если смотреть и разбирать — то какой смысл использовать коды транспорта?
Или в приведенном примере:
если мы пытаемся передать полезную нагрузку со значением email, уже присутствующим в users, то получаем отклик с кодом 400 и сообщение 'User already exists', означающее, что такой пользователь уже существует
А если сообщения локализованы? Как на уровне клиента корректно это обрабатывать, имея только код 400? Если есть ещё код от самого приложения — то см. выше, коды транспорта просто лишены смысла — неясно, ошибся пользователь, указав неверные данные, или приложение где-то словило исключение по независящим от пользователя причинам.
Яркий пример такого неудобства — это PowerDNS API — там на всё код 400 и исключительно текстовые сообщения об ошибках, хорошо хоть не локализованы — но если кто-то решит их изменить хоть на один символ (что уже случалось), то все парсеры пойдут в лес (да, как это не удивительно, но некоторые клиенты создаются с учётом адекватной реакции на ошибки).
Из кода ошибки должно быть ясно сразу и однозначно, где и почему она произошла (транспорт/приложение/валидация/etc), она временная или нет, одна или много, имеет ли смысл повторить запрос позже или "уже всё" и т.д. (примерно как SQL state). Очевидно, что HTTPшных кодов для этого недостаточно и поэтому использовать их для этого мало смысла.
Я обычно при проектировании REST API исхожу из того что все коды ошибок HTTP относятся исключительно к транспорту (т.е. собственно HTTP), и при любом раскладе, если документ попал в приложение и был там обработан, то на выходе должно быть 200 — при любом ответе, с ошибкой или нет, а само тело ответа всегда содержит подробную информацию в случае ошибки в структурированном виде. Если код не 200 — значит он не попал в приложение, со всеми вытекающими.
Из личного опыта — у одного из моих клиентов, которые использовали "чистый REST", пользователи никогда (при первой реализации) не изучают тело ответа при коде отличном от 200, были потрачены тонны тикетов для объяснений почему они должны смотреть внутрь если это не 200. Что примечательно, при переходе на код 200 в следующей версии с ошибками внутри никаких вопросов у новых пользователей уже не возникало.
И наконец, как уже выше заметили, REST это принцип и архитектура, а не спецификация или стандарт, и соответсвенно транспортом когда-нибудь может оказаться вовсе не HTTP — вот почему не стоит делать маппинг ошибок на уровне транспорта — приложение всё равно должно качественно о них сообщать.
Делать файловую систему на JS — это примерно как использовать лошадей вместо двигателя. Ездить можно, но вот как быстро и комфортно… особенно по мере возрастания нагрузок и расстояний.
Это можно сделать и сейчас, создав сайт с чем-то очень наказуемым законами РФ но ненаказуемым законами страны хостинга и регистрации.
Но с другой стороны, если вдруг вы лично (или ваша фирма) окажетесь героем публикации на каком-то сайте, где будет порочащая вас информация — без подобных инструментов вы будете бессильны что-либо сделать. Впрочем, чтобы реально нанести ущерб сайт должен быть популярным и посещаемым, или, как минимум, легко находится в популярных поисковиках.
Ситуация получается патовая — без закона не защищены те кому это действительно может быть нужно, а с законом сравнительно легко подставить неугодных.
Внесут в чёрный список и сделают недоступыми на территории РФ. Если сайты ведут деятельность на территории РФ (магазины и пр.) — им будет больно, потому что большинство не заморачивается с VPN и прочими обходами если это им не очень нужно. Если не ведут — то как минимум они станут недоступны большинству, а меньшинство мало кого волнует.
Основное отличие любого VNC от любого RDP — это потребляемые ресурсы. Первые очень прожорливы и требуют широкого канала для комфортной работы, всё что меньше 100 Mbit будет неприятно ощутимо. При включении компресии и прочих фишек для оптимизации ощутимо повышается нагрузка со стороны сервера (если это "недорогой" VPS).
Если на сервере только текстовые окна, терминалы там и прочее — то всё ещё более-менее, но про графику и тем более видео без сжатия (и соответственно ощутимой потери качества) можно забыть если у вас меньше чем 1Gbit канал.
VNC это что-то вроде стриминга, в то время как RDP это более высокуровневая штука — нечто вроде X11, когда клиент получает команды на отрисовку а не картинку, соответственно, он менее требователен к ресурсам со стороны сервера и канала.
Ради эксперимента — запустите видео через VNC и попробуйте что-то сделать в других окнах, если у вас нет хотя бы 100Mbit то получится с трудом. В то же время RDP вполне себе живёт даже на 10 Mbit, не затрудняя работы. И нет, проблема не только с видео — нагруженное IDE (типа JetBrains) тоже весьма хорошую нагрузку создает (особенно во время скроллинга), простое и банальное перемещение окон ощутимо тормознуто, в то время как по RDP это практически не ощутимо даже на слабых каналах.
Дальше — редко какие VNC позволяют делать нормальный copy&paste (под нормальным я имею в виду не только текст, но также картинки и вообще файлы), не говоря уже про другие ресурсы (расшаренные диски etc), но даже если и умеют то всё равно без бубна и танцев не обойтись.
Если же завернуть VNC в VPN и/или SSH, да ещё по низкоскоростному (со стороны клиента) каналу и до сравнительно слабого VPS то работать так можно только от безысходности.
В общем, VNC вне широкополосных каналов и мощного желела имеет довольно узкую область применения, а если ограничиваться "тонкими" окошками с текстами (которые редко меняются и не скроллятся часто), то нужен ли он вообще?
Так не получится потому что count может быть равен 0 (или даже меньше в случае косяка), в вашем примере цикл выполнится один раз как минимум при любом его значении. for на самом деле это:
i = 0;
while (i < count) {
do_something();
i++;
}
То есть i по определению может быть равно count исключительно в случае когда не было выхода из цикла по break, ибо при выполнии break до его инкремента просто не дойдёт.
Какая-то нестыковочка. Были обнаружены чуть более 50 миллионов, но "сотни миллионов устройств смогут подключаться к Интернету".
А вообще странно что регистраторы не отслеживают использование адресов, как минимум по их наличию в BGP.
И к тому же, "закончились" это совсем некорректный термин применительно к регистраторам верхнего уровня — они просто распределены, реальное же использование и "заканчивание" нужно считать по тем кому они распределены, но этой статистики (глобально) ни у кого нет.
Масса провайдеров имеет кучу свободных адресов в выделенных пулах, и клиенты спокойно их получают, страдают (если можно так выразится) только "гаражные" провайдеры, которые хотят получать их напрямую (потому что дёшево или даже бесплатно).
А зачем сравнивать характеристики, если характеристик даже вышедшего 5 лет назад телефона вполне достаточно для повседневного использования
Смотря как им пользоваться. Если кто-то играется то мощности (и памяти) для новых игр может быть недостаточно, AR тоже ресурсов требует немало (и находит применение не только в играх), да и чем он шустрее тем удобней пользоваться даже простым браузером, особенно если учесть тренд в повальном переходе на JS в вебе. Камера, опять же, тоже немало кушает.
А если пользоваться им только как телефоном и блокнотом — тогда да, проблем нет, можно даже урезать и память, и ядра и даже тактовую, заодно и батарейку сэкономим.
Там не сказано про "намерение активировать", там просто сказано про активирование. Но если уж заниматься буквоедством, то установка Windows 10 с учётом такого соглашения вообще невозможна, с лицензией или без, потому что:
You are authorized to use this software only if you are properly licensed and the software has been properly activated with a genuine product key or by other authorized method.
Вы имеете право использовать это программное обеспечение только в том случае, если вы имеете лицензию и программное обеспечение было должным образом активировано с помощью подлинного ключа продукта или другим авторизованным способом.
Поскольку попытка установки уже является "использованием" (уточнения в соглашении нет), а на этот момент активация ещё не произошла, то это уже незаконно, а если учесть что активацию до установки произвести нельзя (обычному пользователю) то вы нарушаете лицензию почти всегда (хоть и на короткое время).
QUIC конечно хорош, но вот оверхед в userspace будет очень ощутим на больших объемах — клиенты возможно этого не заметят, но вот нагрузка на CPU в серверах ощутимо возрастёт.
Пока его не прикрутят в ядра, "замена TCP" будет дорого обходится, подозреваю что потери в производительности будут сравнимы с теми которые есть у OpenVPN.
если исходный файл утерян, то видимо предполагается сделать OCR или ручной ввод напечатанного мусора с последующей перекодировкой? Или вообще делать это вручную?
Вопрос 4 (и здесь тоже нет)
обычно ls -la показывает владельцев файлов, но в тексте вопроса это почему-то опущено, хотя важно для ответа — так как возможна ситуация когда "правильный" ответ на самом деле неправильный.
Вопрос 8: "gardena" это не "садовый шланг" и вообще не переводится, это название торговой марки и компании которая производит кучу садово-огородного оборудования.
Если вы делаете это не для себя — лучше спросите тех кто будет пользоваться, как им логичнее.
И, как я уже написал чуть раньше — если изменение состояния не предполагает отдачу свойственного только ему данных, всё же как-то логичнее не делать отдельный ресурс, но… это ваш API.
То что написано в статье — одно из мнений. Делайте так как вам подсказывает команда, здравый смысл, клиенты и ТЗ.
REST — это не стандарт и не спецификация, никто вам не может указывать что "можно" а что "нельзя", хотя если пользователи станут возмущаться — к ним всё же стоит прислушаться, потому что вы делаете это для них.
Идеальный API — это тот когда пользователи активно его используют и при этом у них (почти) не возникает вопросов — исходите из этого.
Никто не запрещает действия при изменении свойства, этот ворох изменений может быть сделан во время PATCH при изменении состояния свойста, с соответствующим фидбеком (получилось/нет).
С другой стороны, точно также никто не запрещает создать отдельный ресурс для этого, который будет отличаться только… отдельным ресурсом, в то время как с точки зрения клиента принципиально ничего не меняется — объект активирован, что там произошло для этого "у ней внутре" его не интересует, кроме подтверждения изменения состояния.
Если же активация подразумевает отдачу чего-то очень интимного, свойственного только активации (credentials, token etc) — да, в этом случае уже будет логично создать отдельный ресурс.
POST — создать новый объект. PUT — заменить существующий объект. PATCH — изменить часть существующего объекта. Что тут неочевидно?
Если у объекта есть атрибут "активен" — это часть объекта, так что на любые изменения отдельных частей — это таки PATCH.
Если уж вам хочется что бы всё было отдельно — сделайте user-activation и используйте PUT или POST, хотя это (как мне кажется) менее логично, потому что сразу возникает искушение создать его отдельно от user (и кто-то обязательно это сделает, пусть и неудачно).
Активация это U, потому что пользователь уже существует и де-факто это изменение части объекта. Логично для этой цели использовать PATCH.
Вот спорно очень насчёт кодов ошибок. Потому как, к примеру, 404 — относится к тому что нет маршрута или нет документа? 50x — проблема с транспортом, прокси или самим приложением? Если не смотреть внутрь — то по одному коду непонятно, это проблема endpoint или самого приложения, а если смотреть и разбирать — то какой смысл использовать коды транспорта?
Или в приведенном примере:
А если сообщения локализованы? Как на уровне клиента корректно это обрабатывать, имея только код 400? Если есть ещё код от самого приложения — то см. выше, коды транспорта просто лишены смысла — неясно, ошибся пользователь, указав неверные данные, или приложение где-то словило исключение по независящим от пользователя причинам.
Яркий пример такого неудобства — это PowerDNS API — там на всё код 400 и исключительно текстовые сообщения об ошибках, хорошо хоть не локализованы — но если кто-то решит их изменить хоть на один символ (что уже случалось), то все парсеры пойдут в лес (да, как это не удивительно, но некоторые клиенты создаются с учётом адекватной реакции на ошибки).
Из кода ошибки должно быть ясно сразу и однозначно, где и почему она произошла (транспорт/приложение/валидация/etc), она временная или нет, одна или много, имеет ли смысл повторить запрос позже или "уже всё" и т.д. (примерно как SQL state). Очевидно, что HTTPшных кодов для этого недостаточно и поэтому использовать их для этого мало смысла.
Я обычно при проектировании REST API исхожу из того что все коды ошибок HTTP относятся исключительно к транспорту (т.е. собственно HTTP), и при любом раскладе, если документ попал в приложение и был там обработан, то на выходе должно быть 200 — при любом ответе, с ошибкой или нет, а само тело ответа всегда содержит подробную информацию в случае ошибки в структурированном виде. Если код не 200 — значит он не попал в приложение, со всеми вытекающими.
Из личного опыта — у одного из моих клиентов, которые использовали "чистый REST", пользователи никогда (при первой реализации) не изучают тело ответа при коде отличном от 200, были потрачены тонны тикетов для объяснений почему они должны смотреть внутрь если это не 200. Что примечательно, при переходе на код 200 в следующей версии с ошибками внутри никаких вопросов у новых пользователей уже не возникало.
И наконец, как уже выше заметили, REST это принцип и архитектура, а не спецификация или стандарт, и соответсвенно транспортом когда-нибудь может оказаться вовсе не HTTP — вот почему не стоит делать маппинг ошибок на уровне транспорта — приложение всё равно должно качественно о них сообщать.
Делать файловую систему на JS — это примерно как использовать лошадей вместо двигателя. Ездить можно, но вот как быстро и комфортно… особенно по мере возрастания нагрузок и расстояний.
Это можно сделать и сейчас, создав сайт с чем-то очень наказуемым законами РФ но ненаказуемым законами страны хостинга и регистрации.
Но с другой стороны, если вдруг вы лично (или ваша фирма) окажетесь героем публикации на каком-то сайте, где будет порочащая вас информация — без подобных инструментов вы будете бессильны что-либо сделать. Впрочем, чтобы реально нанести ущерб сайт должен быть популярным и посещаемым, или, как минимум, легко находится в популярных поисковиках.
Ситуация получается патовая — без закона не защищены те кому это действительно может быть нужно, а с законом сравнительно легко подставить неугодных.
Внесут в чёрный список и сделают недоступыми на территории РФ. Если сайты ведут деятельность на территории РФ (магазины и пр.) — им будет больно, потому что большинство не заморачивается с VPN и прочими обходами если это им не очень нужно. Если не ведут — то как минимум они станут недоступны большинству, а меньшинство мало кого волнует.
Основное отличие любого VNC от любого RDP — это потребляемые ресурсы. Первые очень прожорливы и требуют широкого канала для комфортной работы, всё что меньше 100 Mbit будет неприятно ощутимо. При включении компресии и прочих фишек для оптимизации ощутимо повышается нагрузка со стороны сервера (если это "недорогой" VPS).
Если на сервере только текстовые окна, терминалы там и прочее — то всё ещё более-менее, но про графику и тем более видео без сжатия (и соответственно ощутимой потери качества) можно забыть если у вас меньше чем 1Gbit канал.
VNC это что-то вроде стриминга, в то время как RDP это более высокуровневая штука — нечто вроде X11, когда клиент получает команды на отрисовку а не картинку, соответственно, он менее требователен к ресурсам со стороны сервера и канала.
Ради эксперимента — запустите видео через VNC и попробуйте что-то сделать в других окнах, если у вас нет хотя бы 100Mbit то получится с трудом. В то же время RDP вполне себе живёт даже на 10 Mbit, не затрудняя работы. И нет, проблема не только с видео — нагруженное IDE (типа JetBrains) тоже весьма хорошую нагрузку создает (особенно во время скроллинга), простое и банальное перемещение окон ощутимо тормознуто, в то время как по RDP это практически не ощутимо даже на слабых каналах.
Дальше — редко какие VNC позволяют делать нормальный copy&paste (под нормальным я имею в виду не только текст, но также картинки и вообще файлы), не говоря уже про другие ресурсы (расшаренные диски etc), но даже если и умеют то всё равно без бубна и танцев не обойтись.
Если же завернуть VNC в VPN и/или SSH, да ещё по низкоскоростному (со стороны клиента) каналу и до сравнительно слабого VPS то работать так можно только от безысходности.
В общем, VNC вне широкополосных каналов и мощного желела имеет довольно узкую область применения, а если ограничиваться "тонкими" окошками с текстами (которые редко меняются и не скроллятся часто), то нужен ли он вообще?
Так не получится потому что count может быть равен 0 (или даже меньше в случае косяка), в вашем примере цикл выполнится один раз как минимум при любом его значении.
forна самом деле это:То есть
iпо определению может быть равноcountисключительно в случае когда не было выхода из цикла поbreak, ибо при выполнииbreakдо его инкремента просто не дойдёт.Какая-то нестыковочка. Были обнаружены чуть более 50 миллионов, но "сотни миллионов устройств смогут подключаться к Интернету".
А вообще странно что регистраторы не отслеживают использование адресов, как минимум по их наличию в BGP.
И к тому же, "закончились" это совсем некорректный термин применительно к регистраторам верхнего уровня — они просто распределены, реальное же использование и "заканчивание" нужно считать по тем кому они распределены, но этой статистики (глобально) ни у кого нет.
Масса провайдеров имеет кучу свободных адресов в выделенных пулах, и клиенты спокойно их получают, страдают (если можно так выразится) только "гаражные" провайдеры, которые хотят получать их напрямую (потому что дёшево или даже бесплатно).
Неправда. Настоящие параноики пользуются свечами, карандашом и бумагой, и сидят в бункере на глубине минимум 873 метра.
Выделить отдельный SSID с файрволлом и резалкой скорости для IoT — не получится? Многие рутеры это умеют.
Смотря как им пользоваться. Если кто-то играется то мощности (и памяти) для новых игр может быть недостаточно, AR тоже ресурсов требует немало (и находит применение не только в играх), да и чем он шустрее тем удобней пользоваться даже простым браузером, особенно если учесть тренд в повальном переходе на JS в вебе. Камера, опять же, тоже немало кушает.
А если пользоваться им только как телефоном и блокнотом — тогда да, проблем нет, можно даже урезать и память, и ядра и даже тактовую, заодно и батарейку сэкономим.
Платить авансом незнакомому исполнителю, не выяснив предварительно условий и сроков? Однако...
Там не сказано про "намерение активировать", там просто сказано про активирование. Но если уж заниматься буквоедством, то установка Windows 10 с учётом такого соглашения вообще невозможна, с лицензией или без, потому что:
Поскольку попытка установки уже является "использованием" (уточнения в соглашении нет), а на этот момент активация ещё не произошла, то это уже незаконно, а если учесть что активацию до установки произвести нельзя (обычному пользователю) то вы нарушаете лицензию почти всегда (хоть и на короткое время).
Если уж копать, то с учётом acl, capabilities, nfs и ещё кучи всего вариантов явно намного больше чем вероятный +i.
QUIC конечно хорош, но вот оверхед в userspace будет очень ощутим на больших объемах — клиенты возможно этого не заметят, но вот нагрузка на CPU в серверах ощутимо возрастёт.
Пока его не прикрутят в ядра, "замена TCP" будет дорого обходится, подозреваю что потери в производительности будут сравнимы с теми которые есть у OpenVPN.
если исходный файл утерян, то видимо предполагается сделать OCR или ручной ввод напечатанного мусора с последующей перекодировкой? Или вообще делать это вручную?
обычно
ls -laпоказывает владельцев файлов, но в тексте вопроса это почему-то опущено, хотя важно для ответа — так как возможна ситуация когда "правильный" ответ на самом деле неправильный.Вопрос 8: "gardena" это не "садовый шланг" и вообще не переводится, это название торговой марки и компании которая производит кучу садово-огородного оборудования.