Попробуем посмотреть на этот процесс со стороны логики, а не “так делают все”.
У нас есть транспортный слой (HTTP). Я делаю запрос (и даже не важно какой) - и я хочу от транспорта (HTTP) что бы он выполнил свою роль - передачу данных. Ведь сегодня HTTP, завтра HTTP2, затем HTTP3 итак далее. А вот когда я получу сообщение, я как получатель уже буду его читать и принимать бизнес решение - что делать. А мы видим картину что транспорт берет на себя роль участника бизнес процесса, он содержит бизнес указатели (HTTP-коды показывают есть у меня доступ или нет) - хотя от него ожидается просто доставка.
По простому:
200 - объект данных есть
404 - объект данных отсутствует
Я делаю запрос в ендпоинт, а мне говорят 404. Нет кого? Ендпоинта, объекта данных или сработала хитрая (и не верная) бизнес логика и объект есть, но для тебя нет (сейчас, временно, постоянно и т.п.)
или
200 - ендпоинт есть - дальше смотрим что ответил ендпоинт
Верно - очень частая практика. Логическое скрытие сущностей - “то что фактически существует - представляется как отсутствующее” - и вот тут начинается сущий АД, особенно когда ты не просто часть команды разработки SPA, а внешний для Сервиса потребитель.
Для потребителя API такое поведение превращается в многослойный пирог из композиции: http-route * auth-state * global-bussines-action * action = множественная вариация поведения и ответа API.
403 - верно, решает именно эту задачу. Но хочется сказать словами современника - “Можно, а зачем?”. Зачем HTTP-коды, они все равно не могут покрыть даже 95% кейсов и формируется двух этапность обработки результата (HTTP-код + код-приложения). И возникает вопрос зачем лишнее? Пусть транспорт - занимается транспортом, а приложение в рамках контента определяет свою бизнес-логику.
А указываемая проблематика RPC - что все в одной точке, методов становится все больше и дальше ужас, боли и страдания. Может просто надо хорошо организовывать именование методов - можно использовать dotnotatiion-формат ( [model].[action].[subaction].[wtfyoudoing] = user.create user.update user.profile user.profile.edit auth.login auth.logout и т.д.).
Все так любят REST - но мне кажется он не очень корректным когда APP начинает указывать Веб-серверу “врать” о фактическом состоянии запрашиваемых объектов - GET /users/1 и получаем 404 - не потому что такого пользователя нет, а потому что у тебя нет прав (ты авторизован, но не Админ - например) и ты не можешь его видеть. Но получается что адрес на который я сделал запрос не существует, то есть я должен не верить ответу Веб-сервера (его кодам), а оперировать бизнес-логикой приложения, знать (понять прочитав содержимое тела ответа) как работает тот или иной Сервис. И может показаться логичным - что нужно знать и понимать ответы Сервиса, но это не ответы Сервиса - это ответы веб-сервера. В противовес у RPC все более однозначно: HTTP - является чистым транспортом задача которого доставлять данные. Ты сделал запрос (POST /api и получил ответ: 200 OK {“code”:20401,…} - что обозначает код? читайте документацию, ровно так же как нужно читать документацию по REST-сервису, что обозначает его HTTP-код на том или ином пути в той или иной ситуации.
На спектруме, писался загрузчик для блока с "фотками" и потом "методом научного перебора" FOR X = 12000 ... POKE X - выводился блок данных как изображение на экран, вместе со стартовым Битом. Результат записывался на самый надежный носитель (бумажечку - карандашиком) и в последующем, можно было загрузить блок с фото и сразу "смотреть нужное" .
"Ох как часто мы принимаем науку за магию" — я сам.
Был не прав в своем понимании.
Действительно хранятся "слепки" файлов. а небольшие изменения в размерах вызваны просто их "архивацией".
Лично я понял как — деревья используются для хранения данные об файлах их иерархическом положении в древе абстрактной файловой системы для корректного воссоздания структуры.
А по факту при коммите формируется, и храниться дельта изменений.
В противном случаи каждый коммит в файл исходного кода, размером в 1 Мб, должен будет порождать его копию (пусть даже и архивную). Чисто эмперическим путем можно увидеть:
при первичном коммите файла в 1Мб = коммит имеет большой размер (более 1 Мб), т.к. коммит содержит дельту от "ничего" до 1Мб
при следующем коммите (при изменении всего одного символа) мы получаем объем хранимых данных близкий по объему изменений.
Программист написал код — не важно, можно пережить
Конечно, нет. Деятельность разработчиков\программистов и других представителей ИТ-сферы крайне важна, особенно в современном мире.
Логично что высокий спрос на специалистов — порождает более высокие планки оплаты труда.
Но у многих возникает мнение, что если данный рынок труда высокооплачиваемый, то так должно быть с момента входа в него. Приходит джун — и сразу 70к! А за что? Опыта нет. Знания — тоже минимум.
И тут начинается....
"… ну а как же ему стать профессионалам если он не будет учиться… бла-бла-бла..."
А кто сказал, что тебе должны платить за то что ТЫ УЧИШЬСЯ? Учись самостоятельно, развивайся профессионально в проектах вне основной работы. Да, это тяжело и будет выматывать.
К сожалению, подавляющее большинство желающих проявить себя в ИТ стремятся из-за денег, а не из-за самой ИТ, ее возможной.
Думаю каждый из нас знает одного или более людей, которые были довольно далеки от программирования, но они начали заниматься этим из-за личной потребности (устал искать фрилансеров что бы допили сайт, нужна была софтина который нет). Как результат через время эти люди либо получили требуемый результат и отошли от ИТ, или стали продолжать заниматься и стали весьма не плохими разработчиками. Они пришли в эту область — для решения ЗАДАЧИ.
А какую ЗАДАЧУ приходят решать люди, стремящиеся получить должность с большим окладом?
dmbarsukov (не лично вам, а только для продолжения дискуссии).
Разработчик допустивший ошибку в коде ≠ Водитель допустивший ошибку во время движения, хирург во время операции, даже кассир при выдаче сдачи.
Мобильное приложение для банка пройдет семь кругов ада тестов, прежде чем станет использоваться в реальных условиях. И даже если есть невыявленная ошибка, всегда можно откатить на версию назад. В других профессиях такое не (мало) возможно.
Полагаю именно это автор (chapuza) имел сравнивая профессии.
Прочитал как:
«Нам тяжело следить за вами, когда ваши данные на серверах за границей, переносите свои данные на сервера у нас в КГБ серверной, тут они будут в безопасности и нам проще будет следить»
Не соглашусь… про Mac — не знаю… под *nix-подобными — работает.
Может возникнуть проблема со скоростью скроллинга — но не более.
Или опишите более подробно проблему в ПМ
А я как раз за такой вариант и хочу от API
Попробуем посмотреть на этот процесс со стороны логики, а не “так делают все”.
У нас есть транспортный слой (HTTP). Я делаю запрос (и даже не важно какой) - и я хочу от транспорта (HTTP) что бы он выполнил свою роль - передачу данных. Ведь сегодня HTTP, завтра HTTP2, затем HTTP3 итак далее. А вот когда я получу сообщение, я как получатель уже буду его читать и принимать бизнес решение - что делать. А мы видим картину что транспорт берет на себя роль участника бизнес процесса, он содержит бизнес указатели (HTTP-коды показывают есть у меня доступ или нет) - хотя от него ожидается просто доставка.
По простому:
200 - объект данных есть
404 - объект данных отсутствует
Я делаю запрос в ендпоинт, а мне говорят 404. Нет кого? Ендпоинта, объекта данных или сработала хитрая (и не верная) бизнес логика и объект есть, но для тебя нет (сейчас, временно, постоянно и т.п.)
или
200 - ендпоинт есть - дальше смотрим что ответил ендпоинт
Верно - очень частая практика. Логическое скрытие сущностей - “то что фактически существует - представляется как отсутствующее” - и вот тут начинается сущий АД, особенно когда ты не просто часть команды разработки SPA, а внешний для Сервиса потребитель.
Для потребителя API такое поведение превращается в многослойный пирог из композиции: http-route * auth-state * global-bussines-action * action = множественная вариация поведения и ответа API.
403 - верно, решает именно эту задачу. Но хочется сказать словами современника - “Можно, а зачем?”. Зачем HTTP-коды, они все равно не могут покрыть даже 95% кейсов и формируется двух этапность обработки результата (HTTP-код + код-приложения). И возникает вопрос зачем лишнее? Пусть транспорт - занимается транспортом, а приложение в рамках контента определяет свою бизнес-логику.
ИМХО:
Уровень 0: REST
Уровень 1: MOREREST
Уровень 2: HATEOAS
Уровень 0: RPC
А указываемая проблематика RPC - что все в одной точке, методов становится все больше и дальше ужас, боли и страдания. Может просто надо хорошо организовывать именование методов - можно использовать dotnotatiion-формат ( [model].[action].[subaction].[wtfyoudoing] = user.create user.update user.profile user.profile.edit auth.login auth.logout и т.д.).
Все так любят REST - но мне кажется он не очень корректным когда APP начинает указывать Веб-серверу “врать” о фактическом состоянии запрашиваемых объектов - GET /users/1 и получаем 404 - не потому что такого пользователя нет, а потому что у тебя нет прав (ты авторизован, но не Админ - например) и ты не можешь его видеть. Но получается что адрес на который я сделал запрос не существует, то есть я должен не верить ответу Веб-сервера (его кодам), а оперировать бизнес-логикой приложения, знать (понять прочитав содержимое тела ответа) как работает тот или иной Сервис. И может показаться логичным - что нужно знать и понимать ответы Сервиса, но это не ответы Сервиса - это ответы веб-сервера. В противовес у RPC все более однозначно: HTTP - является чистым транспортом задача которого доставлять данные. Ты сделал запрос (POST /api и получил ответ: 200 OK {“code”:20401,…} - что обозначает код? читайте документацию, ровно так же как нужно читать документацию по REST-сервису, что обозначает его HTTP-код на том или ином пути в той или иной ситуации.
На спектруме, писался загрузчик для блока с "фотками" и потом "методом научного перебора" FOR X = 12000 ... POKE X - выводился блок данных как изображение на экран, вместе со стартовым Битом. Результат записывался на самый надежный носитель (бумажечку - карандашиком) и в последующем, можно было загрузить блок с фото и сразу "смотреть нужное" .
Понимаю что не все могут запустить на рабочей машине скрипт (PowerShell), но
Мне весьма помогает
"Я сделаль" — https://jsfiddle.net/ktz3mLvd/5/
У меня такая проблема не воспроизводится (
114172744=11417274423
114472744=11447274411
Пятый разрад — ошибка
370041837=37004183750
370071837=37007183750
https://jsfiddle.net/ktz3mLvd/5/
Примитивно, но работает. Описанная логика (вроде) соблюдена.
Но меня смутило "девять случайных цифр" — то есть множество ведущих нулей допустимо?
"Ох как часто мы принимаем науку за магию" — я сам.
Был не прав в своем понимании.
Действительно хранятся "слепки" файлов. а небольшие изменения в размерах вызваны просто их "архивацией".
Лично я понял как — деревья используются для хранения данные об файлах их иерархическом положении в древе абстрактной файловой системы для корректного воссоздания структуры.
А по факту при коммите формируется, и храниться дельта изменений.
В противном случаи каждый коммит в файл исходного кода, размером в 1 Мб, должен будет порождать его копию (пусть даже и архивную). Чисто эмперическим путем можно увидеть:
Я полагаю имелось ввиду = handle
Конечно, нет. Деятельность разработчиков\программистов и других представителей ИТ-сферы крайне важна, особенно в современном мире.
Логично что высокий спрос на специалистов — порождает более высокие планки оплаты труда.
Но у многих возникает мнение, что если данный рынок труда высокооплачиваемый, то так должно быть с момента входа в него. Приходит джун — и сразу 70к! А за что? Опыта нет. Знания — тоже минимум.
И тут начинается....
К сожалению, подавляющее большинство желающих проявить себя в ИТ стремятся из-за денег, а не из-за самой ИТ, ее возможной.
Думаю каждый из нас знает одного или более людей, которые были довольно далеки от программирования, но они начали заниматься этим из-за личной потребности (устал искать фрилансеров что бы допили сайт, нужна была софтина который нет). Как результат через время эти люди либо получили требуемый результат и отошли от ИТ, или стали продолжать заниматься и стали весьма не плохими разработчиками. Они пришли в эту область — для решения ЗАДАЧИ.
А какую ЗАДАЧУ приходят решать люди, стремящиеся получить должность с большим окладом?
dmbarsukov (не лично вам, а только для продолжения дискуссии).
Разработчик допустивший ошибку в коде ≠ Водитель допустивший ошибку во время движения, хирург во время операции, даже кассир при выдаче сдачи.
Мобильное приложение для банка пройдет семь кругов
адатестов, прежде чем станет использоваться в реальных условиях. И даже если есть невыявленная ошибка, всегда можно откатить на версию назад. В других профессиях такое не (мало) возможно.Полагаю именно это автор (chapuza) имел сравнивая профессии.
«Нам тяжело следить за вами, когда ваши данные на серверах за границей, переносите свои данные на сервера у нас в
КГБсерверной, тут они будут в безопасности и нам проще будет следить»Дополнил статью
Большое спасибо Всем.
Может возникнуть проблема со скоростью скроллинга — но не более.
Или опишите более подробно проблему в ПМ