Comments 11
В чем разница между REST и AJAX
В чем разница между соленым и красным. Типа..
Когда дошел до этого вопроса, то осознал, что меня сильно цепляет в этой статье (ну кроме откровенного догматизма).
Ответы предполагают, не понимание, а тупое заучивание. Да и примеры вопросов ну очень странные.
А.. так это реклама курсов.
Уф. аж от сердца отлегло и стало все понятно (зачем эта статья).
А где тут реклама курсов? Я увидел ссылки только на статьи, их хх и ютубы.
Ну да. Смутил tag "Карьера в IT-индустрии". Ну и статься по уровню "требований к знаниям" аналитика (!) который занимается разработкой API (!) слишком много догматов содержит, далеких от практики. Что уж очень напоминало инфоцыган.
Да ну не настолько. Просто сборная солянка простых вещей, которые гугляться в первой ссылке только под свой вкус и цвет. А так-то +- полезно для краткого содержания. А вот интересную тему patch vs put не затронули.
не.. все в куче. А догматично, потому что REST - это, по факту, благое пожелание и рассуждения на тему "как бы хорошо и красиво могло бы быть". А есть куча нюансов с которыми сталкивается это "как все красиво может быть".
Ну просто для иллюстрации:
Если ресурс на указанном URI отсутствует, PUT создает его.
Это слишком идеально. Так оочень редко делают в жизни, по разным причинам.
POST не является идемпотентным.
Ну разве что в идеальном мире.. Оочень редко встречал именно такую реализацию.
Ибо она чревата проблемами (не возможно отследить повторность).
Ну и полно странного, типа:
может быть закеширован, если указан признак "свежести" данных и установлен заголовок Content-Location (en-US)
en-US - это что и к чему?
Начальная строка, она указывает на предполагаемое действие запроса.
А что это такое в протоколе HTTP? теряюсь в догадках что имелось виду по термином "начальная строка"
Каковы основные части HTTP-ответа? Используемая версия HTTP.
Когда это стало "основной частью" HTTP ответа.
SOAP — это строгий протокол для построения безопасных API.
Причем тут безопасность. Использование wsdl для SOAP и openapi для REST подобных API для описание и генерации кода сервера/клиента не делает API безопасным.
Бесстатусное состояние (Stateless) сервера
Наверное опечатка и местечковый термин. Но уж очень глаз режет.
... и т.д.
Впрочем, какая мне разница.
Хотя, не вижу смысла в "экзаменах", которые раскрывают не глубинные знания, а заученные ответы. Поэтому чуть и побулькал на эту тему что бы разгрузить мозги на 15 минут от работы.
Поддерживаю мнение и сложившееся впечатление.
Отличия REST от GraphQL тоже слабоваты
Неплохая обзорная статья. Думаю, аналитикам будет неплозо посмотреть, как самопроверку перед собеседованием, либо в начале проекта 9вспомнить основы)
Бесстатусное состояние (Stateless) сервера: Сервер не хранит никакой информации о прошлых запросах/ответах. Каждый запрос и ответ содержат всю информацию, необходимую для завершения взаимодействия. Бесстатусное взаимодействие снижает нагрузку на сервер, экономит память и повышает производительность.
По Вашему "Stateless" - это "бесстатусное"?
Stateless - состояние не хранится на сервере. Т.е. в каждом новом запросе мы передаём свой логин/пароль (если в приложении есть авторизация), а также данные для запроса.
https://ru.stackoverflow.com/questions/1242990/Что-такое-stateless-и-statefull
Термин из тех, которые лучше наверно вообще не переводить.
Если вы начинающий аналитик и готовитесь к собесам, рекомендую не учить то, что написано в статье. Если вы этого не понимаете, вас раскусят в 2 счёта, потому что к почти к каждому утверждению в статье нужно подставить что-нибудь типа "обычно", "чисто теоретически", "если следовать букве закона"
25 вопросов и ответов по терминам REST API на собеседовании по вакансии системного аналитика