Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось.
Понятно, что с чего бы человек не начал изучение программирования, у него есть шанс в будущем научиться делать что-то другое хорошо. Но автор этой ^ статьи достаточно категорично заявляет о необходимости изучения C, а автор статьи по ссылке наоборот предупреждает о возможной опасности низкоуровневого программирования в начале карьеры.
Вообще непонятно, на каком основании автор этой делает заявления о чистоте кода. Чистый код на C значительно отличается от чистого кода на Java, Python или JavaScript. Более того, понятие о чистоте кода сильно варьируется в зависимости от области применения — математический код будет выглядеть ужасно для веб-программиста и наоборот. Да даже в двух соседних проектах одной команды из одной области структура и стиль кода может быть совершенно разный (пример — Scala как улучшенная Java и Scala как Haskell на JVM).
Тем более непонятно заявление о глубине знаний (или, о гспд, глубине проработки проблемы). У меня есть пара знакомых без технического образования (как раз из тех, кто хочет "войти в IT"), которые сейчас изучают Java и Python. Первый недавно потратил вечер на изучение дополнительного кода для представления негативных целых чисел, другой незадолго до этого спрашивал про линии кеша процессора. Они знают про инструкции процессора, стратегии работы с памятью, относительную скорость операций и т.д. Но при этом они в жизни не видели C, потому что для достижения цели он им не нужен.
C заставляет глубоко прорабатывать решение проблемы
А в чём глубина приведённого решения на C? Больше кода вижу, отсутствие фукнций высшего порядка (которые как раз полезно изучать) вижу, решение не совсем той задачи, что на других языках, вижу. А вот глубины проработки — не вижу. Да и сама задача на особую глубину не претендует вроде как.
Язык С заставляет делать многое руками и писать высокооптимизированный код. [...] Как по мне, такое должен попробовать каждый профессиональный разработчик. Ну, как минимум, бэкендер.
Оптимизировать нужно то, что рабтоает медленно. В бекенде чаще всего медленно работает база данных (при этом нужно уметь оптимизировать запросы), ввод-вывод (часто помогает асинхронщина), HTTP запросы (можно оптимизировать пулы соединений, например). Опять же, причём тут C?
Если вы научитесь писать чистый код на С, то вам будет легче сделать это на другом, более простом языке.
Можно, но ведь мой вопрос был не про то, как можно использовать такие данные, а про то, какие компании готовы работать с ними в обход закона (например, купив данные на чёрном рынке). Вы можете представить, что какой-нибудь условный Johnson & Johnson приходит к какому-нибудь условному DoubleClick и просит запустить рекламу по данным купленным у неофициальных источников? Любая адекватная компания постарается не подходить к таким сделкам ближе чем на 12 адвокатов. Всё, что касается медицинской и околомедицинской тематики, строго регулируется, там даже при благих намерениях можно попасть на миллиардные штрафы, так что уж говорить про очевидный фрод.
В то же время, есть масса простых, дешёвых и абсолютно законных способов узнать, например, о том, что девушка беременна: поисковые запросы, сайты с товарами для беременных, информационные сайты той же тематики и т.д. Да что уж говорить, я знаю научные статьи о том, как по 3м лайкам в Fb можно узнать политические взгляды и сексуальную ориентацию человека. Так зачем в таких условиях ввязываться в грязные сделки, если вся нужная информация и так элементарно вычисляется по доступным для адвертайзера данным?
Не всё в статье правильно и объективно, есть явный перекос в сторону определённых задач и соответсвующих инструментов.
Как подчеркивает Ричард Сочер, обычно быстрее, проще и дешевле найти и разметить достаточно данных, на которых будет обучаться модель — вместо того, чтобы пытаться оптимизировать сложный метод обучения без учителя.
Во-первых, обычно у нас либо есть задача обучения с учителем (например, сентиментный анализ), либо без учителя (например, сравнение текстов по похожести). В задаче с учителем разметка данных нужна так или иначе: нельзя научить алгоритм отделять положительные твиты от отрицательных, если мы ему предварительно не рассказали, что такое положительный и отрицательный.
Во-вторых, размечать данные дорого и долго. Хорошо, если у вас открытые данные, а принцип разметки легко объяснить — в этом случае можно закинуть данные в Amazon MTurk или Яндекс Толоку и просто подождать пару дней. А вот если данные выгружать в сторонние системы нельзя, или разметка требует определённой экспертизы, создание набора данных может стать просто адски долгим.
Далее следует чеклист, который используется при очистке наших данных
Здесь чувствуется явный перекос в сторону классификации с bag of words представлением на небольшом объёме данных. Если вы хотите разбирать структуру предложений или искать упоминания (dependency parsing & coreference resolution), находить именованные сущности (named entity recognition), переводить или генерировать текст, или даже просто использовать модели на основе рекуррентных или свёрточных сетей, то многие пункты из этого списка могут сделать данные только хуже. Например, попробуйте по словам только в нижнем регистре определить, является ли "cure" упоминанием лекарства или группы "The Cure".
Дальше по тексту смешиваются понятия one-hot encoding (в переводе), bag of words и embeddings, хотя embeddings — это как раз встраивание из пространства с одним измерением на слово в пространство с меньшей размерностью с плотным непрерывным представлением.
Когда дело касается классификации данных, наиболее распространенным способом является логистическая регрессия из-за своей универсальности и легкости толкования
Во-первых, очевидно, что логистическая регрессия покрывает только классификацию на 2 класса. Что делать, если классов больше, автор не рассказывает. Можно было бы додумать статью и вспомнить про софтмакс регрессию, но интерпретировать её коэффициенты уже сложнее.
Во-вторых, даже если у вас очень хорошие данные, и логистическая регрессия выдала в первой десятке максимальных коэффициентов действительно релевантные слова, то остальные 19990 слов вы всё равно не просматриваете. Поэтому аргумент про интерпретируемость для меня выглядит довольно странным.
Данный интерпретатор, работающий по принципу черного ящика, позволяет пользователям объяснять решения любого классификатора на одном конкретном примере при помощи изменения ввода (в нашем случае — удаления слова из предложения) и наблюдения за тем, как изменяется предсказание.
Что будет работать только на классификаторах, которые считают все слова независимыми. Если 2 слова зависимы, удаление одного может привести к непредсказуемым результатам (по-отдельности слова "так" и "себе" значат совсем не то же самое, что "так себе").
[свёрточные сети] обычно гораздо быстрее обучаются, чем большинство сложных подходов NLP (например, LSTM-сети и архитектуры Encoder/Decoder )
Откуда взялось сравнение свёрточных сетей и encoder/decoder архитектур, учитывая, что они решают разные задачи, и вообще encoder/decoder может включать в себя CNN, для меня загадка.
Над самим по себе натуральным рядом не определена вероятность, так что распределением он не является. Хотя он учвствует в определении счётного множества, которое является основой для бесконечных дискретных распределений, это да.
Это уже зависит от целей. Если цель — построить красивую теоретическую систему, то да, наверное это важно. Если же цель менее благородная, но более практическая, то обычно и наивного представление о вероятности хватает для любого практического применения.
Если быть точным, то значения дискретной переменной могут принадлежать конечному (finite) либо счётному (countable) множеству. Счётное множество — это, например, множество всех возможных строк из символов таблицы ASCII. В теории для них тоже можно построить распределение вероятностей, свойства которого будут чем-то средним между свойствами непрерывного и конечного дискретного распределения. На практике мне ещё не приходилось работать с бесконечным набором признаков объекта, да и окунать читателя в детали теории множеств не особо хотелось. Поэтому, я надеюсь, вы простите мне эту маленьку ложь.
(В статье, кстати, ещё много примеров маленькой лжи. Самая большая маленькая ложь, пожалуй, это определение вероятности, которую я сначала показываю на примере подсчёта встречаемости, потом обзываю функцией с шумом, а на самом деле это мера, да ещё и с несколькими возможными интерпретациями; а случайная переменная, соответсвенно, — это измеримая функция. Но последний раз, когда я пытался быть математически точным, люди начинали похрапывать минуте на 8й и выходили с полным отсутствием понимания).
другой сервис, который синхронизирует пользователей себе локально, для чего обращается к нашему и если видит, что его уже нет, то удаляет и у себя, например.
Так он удаляет у себя, а не на нашем сервере. К тому же, если он удаляет пользователя локально, значит для него это что-то вроде кеша и он может потом ещё раз сделать GET и всё восстановить.
Я понимаю, что автор хотел показать разницу между транспортным и логическим уровнем, но в этом треде уже довольно много комментариев, но пока никто так и не привёл более или менее реального пример, когда описанная ситуация могла на самом деле случиться. Теоретически — это возможно, на практике — ситуация надуманная.
Какой http-код вы возвращаете если вам нужно сказать клиенту, что транзакция длилась слишком долго и была отменена? [...] Всё верно, проблема только, что на все случаи кодов нет и особенно для более сложных api всё равно приходится что-то придумывать сверх того, что есть.
Лично я бы использовал 422 (unprocessable entity), но если сомневаетесь, возвращайте 400 (bad request) и пояснение. Расспространённое заблуждение, что HTTP коды должны описывать все возможные ситуации и ошибки, но по сути это классы ошибок, а внутри ответа уже может быть указана точная причина. Это ничем не отличается, например, от классов исключительных ситуаций (скажем, OSError или LookupError в Python), которые покрывают сразу массу возможных причин, а точная проблема диагностируется по полям эксепшена.
В заключении вы говорите о том, что автор привык к soap
Не совсем, я говорил про окружение, из которого пришёл автор. Насколько я понимаю, автор пишет с точки зрения энтерпрайз приложений и сложных интеграций. Это не публичные сервисы, кто попало к ним не обращается, а если уж используют, то сразу много всего. SOAP был не так уж и плох для таких интеграций, *RPC во многом повторяют возможности SOAP, по крайней мере, автор прямо говорит о том, что старался перейти на RPC в своём домене.
Но есть масса других доменов, где требования совершенно другие. От GitHub API мне не нужны все 250 эндпойнтов, я хочу просто доставать количество звёзд проекта. От StackOverflow мне не нужен полноценный клиент, мне достаточно уметь считывать текст вопроса и теги. С другой стороны, мне это надо делать из разных языков, в т.ч. тех, для которых нет *RPC клиента. И если я смогу для своего запроса использовать обычный, доступный везде HTTP с уже знакомой семантикой (знакомые "глаголы", коды, с которыми я уже работал и т.д.), то это, как ни крути, большой плюс.
Нажали ссылку где? В письме GET запросом по URL без аутентификации в аккаунт?
За свою жизнь я не видел ни одного ресурса, где аккаунт можно было бы удалить просто нажав кнопку. Обычно для этого нужно войти в свой аккаунт и в "опасной зоне" своего профиля нажать красную кнопку, а затем ещё и подтвердить паролем. И даже после этого аккаунт обычно помечается как "удалённый", но у пользователя есть N дней, чтобы отменить действие.
И это не говоря уже о том, что игра могла не работать из-за десятка других причин — проблем сети, неудачного деплоя, бага, перегрузки сервера и т.д. И есть десяток способов защититься от этого — алертинг, автоматическое и ручное тестирование, мониторинг внешними инструментами. Но виноват, конечно, REST.
Все locations работают, кроме одного. Но самого важного для пользователей
Опять же, речь ведь идёт про внешний сервис, с UI, пользователями и всем таким? Значит пользователь не знает ни про какие locations, ему нужно войти в свой аккаунт, найти кнопку "delete my account" и нажать на неё. Но войти он не может, потому что 404.
Автоматические программы могли бы знать про locations, но если такая программа делает DELETE /myobject после того как GET /myobject вернул 404 — это тоже, мягко говоря, странное поведение.
А как они обрабатывали стандартные и полустандартные коды? Хотя бы 201, 204, 409, 422? Как обрабатывали 302 — постандарту или как браузеры?
302 для API ни разу не использовал — это, всё-таки, публичный контракт, и в эндпойнтах лучшше поддерживать обратную совместимость. Если очень хочется переместить ресурс, то лучше увеличивать версию API.
Остальные коды обрабатывались в соответствии с логикой, описанной в документации. Если какой-то код не описан в документации, то и обрабатывать его не надо.
Я, в основном, реагировал на конкретные фразы в статье, которые у меня вызвали недоумение и ощущение "запугивания" читателя. Ну вот, например:
Использовать HTTP 404 Not Found для уведомления об отсутствующем ресурсе — звучит чертовски по-RESTful, верно? Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…
Речь, судя по всему, идёт про внешние ресурсы а-ля интернет-магазинов, т.е. не про внутренние сервисы, которые общаются автоматически. Соответственно, девопс или админ продеплоил конфигурацию nginx, не проверил, работает ли оно, на сервере не был настроен алертинг и никакие внешние сервисы типа pingdom? Ну ок, не очень ответственный человек, но поверим. Но, если пользователи не могут войти в свой аккаунт, то как они "вычищают" их? Т.е. вся ситуация выглядит притянутой за уши.
Ну или вот:
В результате, как и большинство пользователей REST, вы, вероятно, для выражения исключений в своём приложении используете случайные HTTP-коды вроде HTTP 418 I’m a teapot или вообще неприсвоенные номера. [...] Удачи вам в общении с такими API из автономных программ.
За последние 3-4 года я написал штук 20 REST-сервисов, и ни в одном не использовал "левые" коды, как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше — подождать (503), запросить авторизацию (401 / 403), создать тикет (500) или нормально обработать результат (200). Люди, с которым я работал, тоже никогда так не делали. Публичные API, с которыми приходилось работать, тоже использовали коды по назначению. Тем не менее, автор делает необоснованные предположения, либо чтобы усилить свой аргумент, либо потому что привык к другой среде, о чём я и написал в заключении.
Я писал сервисы, которые общались друг с другом по SOAP, REST, Websockets (включая подпротоколы), голому TCP, AMQP, NATS, Kafka и т.д., поэтому, наверное, я всё-таки немного в теме. И даже если допустить, что статью целиком я не понял, отдельные фразы вроде указанных выше интерпретировать иначе чертовски сложно.
Товарищи, которые минусуют, вы хоть комментарии какие-нибудь оставьте. А то видно, что вы не согласны, но с чем и почему, остаётся только догадываться :)
По Swagger / OpenAPI описанию можно генерировать клиента (например), плюс многие библиотеки сразу дают красивый UI с примерами запросов, от чего клиенты обычно в восторге.
HTTP — стандарт, хорошо задукоментированный. Пути, как правильно, достаточно понятны. Хочется большей точности — пишите документацию, тут никак не отвертишься, ни в случае с REST, ни в случае с чем-то ещё — ни SOAP, ни GraphQL не покроют всех деталей.
Какую URL-endpoint вы присваиваете каждому «ресурсу»? Да, это просто, но приходится делать в любом случае. [...] Как вы сопоставите точные функции из приведённого примера с CRUD-операциями?
Здесь автор предполагает, что API просто оборачивает какую-то БД, где есть какие-то таблицы-ресурсы. Но API может делать много чего другого — запускать процессы на кластере, делать вычисления, обращаться к другим API и т.д. Какой протокол покроет это? XML-схема здесь чем-нибудь поможет?
Паршивое решение: ваш nginx был ошибочно сконфигурирован на один час, так что пользователи вашего API получают только ошибки 404 и вычищают сотни аккаунтов, думая, что они удалены…
Откройте для себя www.pingdom.com иди десятки подобных ресурсов. Сайт может упасть по десяткам причин, с таким же успехом можно делать быстрые правки по SSH прямо на сервере и не проверять результат.
Хотите с помощью PUT обновлять свои ресурсы? [...] Хотите для обновления своего ресурса использовать PATCH? [...] Хотите удалять ресурсы с помощью DELETE?
Ок, если такие проблемы, используйте везде POST. Не по стандарту? Да, наверное, и что? Покрыть стандартом 100% случаев невозможно, но вас никто и не заставляет в точности следовать стандарту. REST вполне неплохо описывает то, что от вас будут ожидать пользователи, например, что GET не будет менять состояние, что DELETE удалит объект и т.п., но если в некоторых случаях такое поведение невозможно, пометьте эту часть в документации жирным.
В общем и целом видно, что автор пришёл из определённого окружения, где SOAP хорошо работал, а REST работает хуже. Ну ок, нет серебрянной пули и всё такое. Но кроме окружения автора есть ещё сотни и тысячи вариантов использования, где REST если не оптимален, то как минимум лучше тяжеловесных решений типа SOAP.
Из второго абзаца той статьи:
Понятно, что с чего бы человек не начал изучение программирования, у него есть шанс в будущем научиться делать что-то другое хорошо. Но автор этой ^ статьи достаточно категорично заявляет о необходимости изучения C, а автор статьи по ссылке наоборот предупреждает о возможной опасности низкоуровневого программирования в начале карьеры.
Вообще непонятно, на каком основании автор этой делает заявления о чистоте кода. Чистый код на C значительно отличается от чистого кода на Java, Python или JavaScript. Более того, понятие о чистоте кода сильно варьируется в зависимости от области применения — математический код будет выглядеть ужасно для веб-программиста и наоборот. Да даже в двух соседних проектах одной команды из одной области структура и стиль кода может быть совершенно разный (пример — Scala как улучшенная Java и Scala как Haskell на JVM).
Тем более непонятно заявление о глубине знаний (или, о гспд, глубине проработки проблемы). У меня есть пара знакомых без технического образования (как раз из тех, кто хочет "войти в IT"), которые сейчас изучают Java и Python. Первый недавно потратил вечер на изучение дополнительного кода для представления негативных целых чисел, другой незадолго до этого спрашивал про линии кеша процессора. Они знают про инструкции процессора, стратегии работы с памятью, относительную скорость операций и т.д. Но при этом они в жизни не видели C, потому что для достижения цели он им не нужен.
А в чём глубина приведённого решения на C? Больше кода вижу, отсутствие фукнций высшего порядка (которые как раз полезно изучать) вижу, решение не совсем той задачи, что на других языках, вижу. А вот глубины проработки — не вижу. Да и сама задача на особую глубину не претендует вроде как.
Оптимизировать нужно то, что рабтоает медленно. В бекенде чаще всего медленно работает база данных (при этом нужно уметь оптимизировать запросы), ввод-вывод (часто помогает асинхронщина), HTTP запросы (можно оптимизировать пулы соединений, например). Опять же, причём тут C?
Или наоборот.
Можно, но ведь мой вопрос был не про то, как можно использовать такие данные, а про то, какие компании готовы работать с ними в обход закона (например, купив данные на чёрном рынке). Вы можете представить, что какой-нибудь условный Johnson & Johnson приходит к какому-нибудь условному DoubleClick и просит запустить рекламу по данным купленным у неофициальных источников? Любая адекватная компания постарается не подходить к таким сделкам ближе чем на 12 адвокатов. Всё, что касается медицинской и околомедицинской тематики, строго регулируется, там даже при благих намерениях можно попасть на миллиардные штрафы, так что уж говорить про очевидный фрод.
В то же время, есть масса простых, дешёвых и абсолютно законных способов узнать, например, о том, что девушка беременна: поисковые запросы, сайты с товарами для беременных, информационные сайты той же тематики и т.д. Да что уж говорить, я знаю научные статьи о том, как по 3м лайкам в Fb можно узнать политические взгляды и сексуальную ориентацию человека. Так зачем в таких условиях ввязываться в грязные сделки, если вся нужная информация и так элементарно вычисляется по доступным для адвертайзера данным?
А вы много знаете компаний, производящих товары для беременных и готовых работать с чёрным рынком? :)
Не всё в статье правильно и объективно, есть явный перекос в сторону определённых задач и соответсвующих инструментов.
Во-первых, обычно у нас либо есть задача обучения с учителем (например, сентиментный анализ), либо без учителя (например, сравнение текстов по похожести). В задаче с учителем разметка данных нужна так или иначе: нельзя научить алгоритм отделять положительные твиты от отрицательных, если мы ему предварительно не рассказали, что такое положительный и отрицательный.
Во-вторых, размечать данные дорого и долго. Хорошо, если у вас открытые данные, а принцип разметки легко объяснить — в этом случае можно закинуть данные в Amazon MTurk или Яндекс Толоку и просто подождать пару дней. А вот если данные выгружать в сторонние системы нельзя, или разметка требует определённой экспертизы, создание набора данных может стать просто адски долгим.
Здесь чувствуется явный перекос в сторону классификации с bag of words представлением на небольшом объёме данных. Если вы хотите разбирать структуру предложений или искать упоминания (dependency parsing & coreference resolution), находить именованные сущности (named entity recognition), переводить или генерировать текст, или даже просто использовать модели на основе рекуррентных или свёрточных сетей, то многие пункты из этого списка могут сделать данные только хуже. Например, попробуйте по словам только в нижнем регистре определить, является ли "cure" упоминанием лекарства или группы "The Cure".
Дальше по тексту смешиваются понятия one-hot encoding (в переводе), bag of words и embeddings, хотя embeddings — это как раз встраивание из пространства с одним измерением на слово в пространство с меньшей размерностью с плотным непрерывным представлением.
Во-первых, очевидно, что логистическая регрессия покрывает только классификацию на 2 класса. Что делать, если классов больше, автор не рассказывает. Можно было бы додумать статью и вспомнить про софтмакс регрессию, но интерпретировать её коэффициенты уже сложнее.
Во-вторых, даже если у вас очень хорошие данные, и логистическая регрессия выдала в первой десятке максимальных коэффициентов действительно релевантные слова, то остальные 19990 слов вы всё равно не просматриваете. Поэтому аргумент про интерпретируемость для меня выглядит довольно странным.
Что будет работать только на классификаторах, которые считают все слова независимыми. Если 2 слова зависимы, удаление одного может привести к непредсказуемым результатам (по-отдельности слова "так" и "себе" значат совсем не то же самое, что "так себе").
Откуда взялось сравнение свёрточных сетей и encoder/decoder архитектур, учитывая, что они решают разные задачи, и вообще encoder/decoder может включать в себя CNN, для меня загадка.
Над самим по себе натуральным рядом не определена вероятность, так что распределением он не является. Хотя он учвствует в определении счётного множества, которое является основой для бесконечных дискретных распределений, это да.
Это уже зависит от целей. Если цель — построить красивую теоретическую систему, то да, наверное это важно. Если же цель менее благородная, но более практическая, то обычно и наивного представление о вероятности хватает для любого практического применения.
Поправил, спасибо.
Хм, согласен. Наверное, распределение Пуассона сюда тоже попадёт, хотя я его плохо знаю. Убрал "конечное", спасибо за пример.
Всё верно, задача с небольшим подвохом, чтобы ответ совсем уж очевидным не был.
Если быть точным, то значения дискретной переменной могут принадлежать конечному (finite) либо счётному (countable) множеству. Счётное множество — это, например, множество всех возможных строк из символов таблицы ASCII. В теории для них тоже можно построить распределение вероятностей, свойства которого будут чем-то средним между свойствами непрерывного и конечного дискретного распределения. На практике мне ещё не приходилось работать с бесконечным набором признаков объекта, да и окунать читателя в детали теории множеств не особо хотелось. Поэтому, я надеюсь, вы простите мне эту маленьку ложь.
(В статье, кстати, ещё много примеров маленькой лжи. Самая большая маленькая ложь, пожалуй, это определение вероятности, которую я сначала показываю на примере подсчёта встречаемости, потом обзываю функцией с шумом, а на самом деле это мера, да ещё и с несколькими возможными интерпретациями; а случайная переменная, соответсвенно, — это измеримая функция. Но последний раз, когда я пытался быть математически точным, люди начинали похрапывать минуте на 8й и выходили с полным отсутствием понимания).
А ведь и правда, пропустил эту деталь. Добавил "нормально распределённая случайная переменная".
Спасибо!
Так он удаляет у себя, а не на нашем сервере. К тому же, если он удаляет пользователя локально, значит для него это что-то вроде кеша и он может потом ещё раз сделать
GETи всё восстановить.Я понимаю, что автор хотел показать разницу между транспортным и логическим уровнем, но в этом треде уже довольно много комментариев, но пока никто так и не привёл более или менее реального пример, когда описанная ситуация могла на самом деле случиться. Теоретически — это возможно, на практике — ситуация надуманная.
Лично я бы использовал 422 (unprocessable entity), но если сомневаетесь, возвращайте 400 (bad request) и пояснение. Расспространённое заблуждение, что HTTP коды должны описывать все возможные ситуации и ошибки, но по сути это классы ошибок, а внутри ответа уже может быть указана точная причина. Это ничем не отличается, например, от классов исключительных ситуаций (скажем,
OSErrorилиLookupErrorв Python), которые покрывают сразу массу возможных причин, а точная проблема диагностируется по полям эксепшена.Не совсем, я говорил про окружение, из которого пришёл автор. Насколько я понимаю, автор пишет с точки зрения энтерпрайз приложений и сложных интеграций. Это не публичные сервисы, кто попало к ним не обращается, а если уж используют, то сразу много всего. SOAP был не так уж и плох для таких интеграций, *RPC во многом повторяют возможности SOAP, по крайней мере, автор прямо говорит о том, что старался перейти на RPC в своём домене.
Но есть масса других доменов, где требования совершенно другие. От GitHub API мне не нужны все 250 эндпойнтов, я хочу просто доставать количество звёзд проекта. От StackOverflow мне не нужен полноценный клиент, мне достаточно уметь считывать текст вопроса и теги. С другой стороны, мне это надо делать из разных языков, в т.ч. тех, для которых нет *RPC клиента. И если я смогу для своего запроса использовать обычный, доступный везде HTTP с уже знакомой семантикой (знакомые "глаголы", коды, с которыми я уже работал и т.д.), то это, как ни крути, большой плюс.
Нажали ссылку где? В письме
GETзапросом по URL без аутентификации в аккаунт?За свою жизнь я не видел ни одного ресурса, где аккаунт можно было бы удалить просто нажав кнопку. Обычно для этого нужно войти в свой аккаунт и в "опасной зоне" своего профиля нажать красную кнопку, а затем ещё и подтвердить паролем. И даже после этого аккаунт обычно помечается как "удалённый", но у пользователя есть N дней, чтобы отменить действие.
И это не говоря уже о том, что игра могла не работать из-за десятка других причин — проблем сети, неудачного деплоя, бага, перегрузки сервера и т.д. И есть десяток способов защититься от этого — алертинг, автоматическое и ручное тестирование, мониторинг внешними инструментами. Но виноват, конечно, REST.
Так вы пример такой ситуации-то приведите.
Опять же, речь ведь идёт про внешний сервис, с UI, пользователями и всем таким? Значит пользователь не знает ни про какие locations, ему нужно войти в свой аккаунт, найти кнопку "delete my account" и нажать на неё. Но войти он не может, потому что 404.
Автоматические программы могли бы знать про locations, но если такая программа делает
DELETE /myobjectпосле того какGET /myobjectвернул 404 — это тоже, мягко говоря, странное поведение.302 для API ни разу не использовал — это, всё-таки, публичный контракт, и в эндпойнтах лучшше поддерживать обратную совместимость. Если очень хочется переместить ресурс, то лучше увеличивать версию API.
Остальные коды обрабатывались в соответствии с логикой, описанной в документации. Если какой-то код не описан в документации, то и обрабатывать его не надо.
Эээ, так а о чём тогда статья?
Я, в основном, реагировал на конкретные фразы в статье, которые у меня вызвали недоумение и ощущение "запугивания" читателя. Ну вот, например:
Речь, судя по всему, идёт про внешние ресурсы а-ля интернет-магазинов, т.е. не про внутренние сервисы, которые общаются автоматически. Соответственно, девопс или админ продеплоил конфигурацию nginx, не проверил, работает ли оно, на сервере не был настроен алертинг и никакие внешние сервисы типа pingdom? Ну ок, не очень ответственный человек, но поверим. Но, если пользователи не могут войти в свой аккаунт, то как они "вычищают" их? Т.е. вся ситуация выглядит притянутой за уши.
Ну или вот:
За последние 3-4 года я написал штук 20 REST-сервисов, и ни в одном не использовал "левые" коды, как раз потому что к моим сервисам обращались автономные программы, которые по коду понимали, что делать дальше — подождать (503), запросить авторизацию (401 / 403), создать тикет (500) или нормально обработать результат (200). Люди, с которым я работал, тоже никогда так не делали. Публичные API, с которыми приходилось работать, тоже использовали коды по назначению. Тем не менее, автор делает необоснованные предположения, либо чтобы усилить свой аргумент, либо потому что привык к другой среде, о чём я и написал в заключении.
Я писал сервисы, которые общались друг с другом по SOAP, REST, Websockets (включая подпротоколы), голому TCP, AMQP, NATS, Kafka и т.д., поэтому, наверное, я всё-таки немного в теме. И даже если допустить, что статью целиком я не понял, отдельные фразы вроде указанных выше интерпретировать иначе чертовски сложно.
Товарищи, которые минусуют, вы хоть комментарии какие-нибудь оставьте. А то видно, что вы не согласны, но с чем и почему, остаётся только догадываться :)
По Swagger / OpenAPI описанию можно генерировать клиента (например), плюс многие библиотеки сразу дают красивый UI с примерами запросов, от чего клиенты обычно в восторге.
Не прочувствовал проблемы.
HTTP — стандарт, хорошо задукоментированный. Пути, как правильно, достаточно понятны. Хочется большей точности — пишите документацию, тут никак не отвертишься, ни в случае с REST, ни в случае с чем-то ещё — ни SOAP, ни GraphQL не покроют всех деталей.
Здесь автор предполагает, что API просто оборачивает какую-то БД, где есть какие-то таблицы-ресурсы. Но API может делать много чего другого — запускать процессы на кластере, делать вычисления, обращаться к другим API и т.д. Какой протокол покроет это? XML-схема здесь чем-нибудь поможет?
Откройте для себя www.pingdom.com иди десятки подобных ресурсов. Сайт может упасть по десяткам причин, с таким же успехом можно делать быстрые правки по SSH прямо на сервере и не проверять результат.
Ок, если такие проблемы, используйте везде POST. Не по стандарту? Да, наверное, и что? Покрыть стандартом 100% случаев невозможно, но вас никто и не заставляет в точности следовать стандарту. REST вполне неплохо описывает то, что от вас будут ожидать пользователи, например, что GET не будет менять состояние, что DELETE удалит объект и т.п., но если в некоторых случаях такое поведение невозможно, пометьте эту часть в документации жирным.
В общем и целом видно, что автор пришёл из определённого окружения, где SOAP хорошо работал, а REST работает хуже. Ну ок, нет серебрянной пули и всё такое. Но кроме окружения автора есть ещё сотни и тысячи вариантов использования, где REST если не оптимален, то как минимум лучше тяжеловесных решений типа SOAP.