Комментарии 26
А как же вопросы про js?!
> 8. Чем отличаются PUT- и POST-запросы?
Ну вы хоть думайте, прежде чем такое писать. Это просто разные методы запроса. Все. Конец.
Никаких «этот только обновляет данные», «этот идемпотентный».
Можно сделать удаление данных на PUT и добавление на DELETE. Это лишь реализация.
Когда задается вопрос, некоторые его детали могут быть упущены, умышленно или нет. Так сказать отвечай как знаешь, или задавай уточняющие вопросы, если в этом возникла необходимость. Это так же может быть одним из этапов проверки, как поведет себя человек, просто ответит или уточнит перед тем как ответчать.
Автор ожидает услышать разницу в использовании. Вот этого слова не хватает в вопросе — «использовании», тогда и ответ хорошо подходит. А так, можно ответить по разному, и эти ответы могут считаться как правильные, в зависимости от ожиданий задающего вопрос человека.
Как гласит поговорка: правильно поставленный вопрос — это уже половина ответа.
О разности POST и PUT в RFC:
tools.ietf.org/html/rfc7231#section-4.3.4
The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.
Также POST используется для вызова Controller (REST, 4-й Resource Archetype).
Вопрос был «чем отличаются» — отличаются строчкой method. Все.
Вы своими ответами с углублениями в протоколы докатитесь до физического уровня. А че, там напряжение будет разное в PUT и POST в разные моменты времени.
Так же как с id и классами, может быть несколько элементов с одинаковыми id и их без проблем можно получить через селекторные запросы. И класс может быть представлен всего одним элементом. Это всего лишь соглашение.
Теперь мне понятно, почему большинство современных веб приложений такие глючные и костыльнве. Все они построены на отаетах на эти вопросы. То есть, без какой либо логики и проектирования базовой архитектуры. Куда катится отрасль.
Вы реально такие вопросы задаете?! Ну просто они только для совсем джунов годятся
Когда-то ещё студентом читал книжку по html/css и там был момент, когда автор рассказывает в чем отличие тега < b > от < strong > и говорит, что такое обязательно! спросят на собеседовании.
На первых собеседованиях, конечно же, ждал такого вопроса :)))
я думаю, что автор сам придумал эти вопросы, чтобы написать еще одну мусорную статью на медиуме.
мне кажется сейчас фреймворки больше значения имеют чем такие обрывочные сведения, потому что знание фреймворка показывает опыт, которого может и не быть даже при знании ответов на все эти вопросы
Мне кажется что эти вопросы не показывают знаний как фронтендера, как верстальщика возможно. Всю статью можно было сократить в 2 линки в итоге.
Спасибо за статью. Вопросы перечисленные здесь и ответы на них весьма общие и ничего не раскрывают о соискателей, чтобы что-то понять о человеке и его опыте нужно задать еще столько же более глубоких вопросов и приправить это все добротным слоем онлайн кодинга. А то знание этого списка, даже на джуна не особо дотягивает.
Ложным в JavaScript является значение false и все. То о чем идёт речь в посте — скорее звучит как "квази ложные" или falsely.
Готовимся к собеседованию по фронтенду: 15 вопросов