Вроде понимаю на простом уровне протоколы: заголовки, тело запроса, модель протоколов и тд, но всеравно куча материала и вещей, которые не понимаю по примерам в коде и гайдах. Всякие токены, заголовки, что-то куда-то не понятно передается и каким образом это происходит.
Одно дело написать Rest CRUD приложение, где бек просто отдает json и ты с этими обьектами что-то вырисовуешь, а другое дело начать смотреть как делается авторизация и другие более сложные вещи, где используются всякие jwt и тд.
Есть может какая-то книга, которая максимально раскрывает все про http, rest/mvc и прочие термины веб разработки. Или как все разработчики понимают эти вещи? Откуда берут? Или это очень простые вещи, прсто я тупой?
Если на OAuth2.0 посмотреть прозрачно и плнять, зачем, потом как - все станет понятно...
Нет сессии, надо как-то аутентификацию сделать. Лелаем через токен, но его могут угнать, значит пара токенов, один для обмена, другой для восстановления...
Ну и т.д... Ларец откроется
rest/mvc и прочие термины веб разработки. Или как все разработчики понимают эти вещи? Откуда берут? Или это очень простые вещи, прсто я тупой?
Секрет прост - большинство разработчиков не понимают эти вещи и используют баззворды не по назначению, прочитав пару статей с Хабра.
REST в принципе не про CRUD, а вместо классического MVC на бэкенде используется Mediating Controller MVC.
Википедию можете почитать, но это не то на чем стоит зацикливаться.
Практика. Ваша теория с протоколами нафиг никому не упала, разве что перед своим работодателем попрыгать на задних лапках, выбивая себе тыщу-другую к премии.
Объем очень большой если хотите понять все то приготовьтесь потратить годы. И учтите что то что вы будете читать сейчас - через несколько лет уже устареет и надо будет это забыть чтобы прочитать что-то новое.
Но если сильно хочется - то читать все подряд, начиная со спецификаций-документаций, потом статьи на тему "а мы вот так это использовали" заканчивая тикетами в трекерах и вопросами на stackoverflow в духе "почему эта фигня не работает хотя должна" и ответами "ну, в таком-то движке в такой-то либе этой версии немного отступили от стандартов и поэтому если сделать вот так и так оно ломается, но можно вместо этого сделать вот так и тогда все ок".
И дальше, падение в эту черную дыру бесконечно.
Можно подойти по другому - брать конкретные задачи, формулировать конкретные вопросы и искать на них ответы и решения и в них уже вникать.
Так вы не будете знать "все" но научитесь быстро узнавать нужное, а для этого надо уметь самому понимать что читать и быть в состоянии за 15 минут пересмотреть 20 статей и ссылок чтобы найти ту где написано вам нужное.
Хотя если у вас цель научиться писать готовый рабочий код ручкой в блокноте сидя в джуглях амазонии без контакта с цивилизацией используя исключительно накопленные в голове знания, то этот подход не подойдет.
спасибо, но всеравно, бекенд же редко меняется, мне казалось.
подходы к таким вещам тоже, или нет?
я думал только фронтенд меняются и технологии в них, а сам принцип работы таких вещей остается понятным и в новых.
допустим я изучаю spring framework. в не есть security технология, в примерах кода, гайдах по нему, описывается много тех вещей, которые сложно понять, из-за терминов и понимания какая цепочка действий происходит в запущенном приложении.
С такой точки зрения да - есть какие-то базовые вещи и в джаве тем более это все меняется медленнее.
В таком случае вам лучше конкретизировать вопрос - я уверен что по spring есть достаточно неплохо написанных материалов.
Нет книги где раскрывается rest,mvc,security, архитектура, авторизация, детали работы какого-то фреймворка и все остальное за раз. Есть материалы по каждому из этих слов отдельно.
Если для вас просто сильно много непонятных терминов - то берете один, читаете про него общие вещи, берете второй, читаете и так далее, сразу все в деталях не поймете, но с каждым разом будет становиться все понятнее и понятнее.
Если вам неясно что там конкретно в spring происходит - то тут первый помощник это документация. У всех зрелых фреймворков она достаточно хорошая. Термины зачастую там же вводятся и используются.
Если например написано что в какой-то момент времени срабатывает Guard, то что это такое надо читать в этой же доке. В другом фреймворке это слово будет значить что-то совсем другое и работать будет по другому и тп.
Я бы вам посоветовал взять один зрелый фреймворк, и прочитать его документацию полностью. А потом уже уточнять моменты на которые вы ответов в этой самой документации не нашли или нашли но не поняли.
