Pull to refresh

Comments 28

28 Почему для конфиденциальных данных рекомендуется использовать POST, а не GET запросы?

Странный ответ, учитывая, что если у нас HTTP, то и GET и POST отправляются открытым текстом, а при HTTPS у нас шифруется соединение полностью, в том числе и url.
29 Можно ли передать в запросе один и тот же параметр несколько раз?
Да, можно принять все значения, используя массив в методе контроллера

Насколько я помню, можно в качестве аргумента использовать любую подходящую коллекцию: List, Set
Можно еще как минимум через запятую перечислить значения, и тогда он сам разобьет на отдельные значения и положит в коллекцию.
Странный ответ, учитывая, что если у нас HTTP, то и GET и POST отправляются открытым текстом, а при HTTPS у нас шифруется соединение полностью, в том числе и url.

Теоретически можно из истории гет-параметры вытащить можно (и при xss есть какие-то шансы), в то время как post-параметры вытащить скриптом не удастся.

Дело в том, что в отличии от POST запроса содержимое GET запроса осядет на каждом узле через который этот запрос прошел. Посмотрите что Apache записывает в access.log
"GET /api/auth/?user=user&password=password&client_id=12345 HTTP/1.1" 200 

"POST /api/auth/ HTTP/1.1" 200

Помимо логов запросы можно сохранять и в других местах для последующей аналитики/статистики. Например статистика просмотров определенного URL.

При особом умении можно добиться чтобы конфиденциальные данные от твоего сервиса можно было искать в google по inurl.

Так что для конфиденциальной информации только POST.

Видимо автор оригинального поста поленился разобраться и надергал по паре предложений из гугла.
И HTTPS в ответе тоже не отсюда. HTTPS защитит трафик от промежуточных узлов, но конечный сервер расшифрует все содержимое перед обработкой запроса и положит весь GET запрос в свой лог.

Ответ ещё страннее, учитывая что GET запросом можно точно так же body передавать.
Это считается антипаттерном и некоторые REST-клиенты (постман вроде) не разрешают body в GET, но тем не менее разница между GET и POST вкладывается человеком, а никак не протоколом.

В 21 пункте опечатка: SUCCESS(500) (должно быть 200)
Спасибо, поправил

28 неверный ответ, опасный даже. без шифрования промежуточные узлы могут прочитать и тело и адрес. С шифрованием не прочитать ни тело ни адрес запроса. А GET/POST история совсем другая. История браузера, глаза соседа, случайное копирование из адресной строки, кеширование, идемпотентность.

Но там же есть и уточнение про https
в том и дело, что нарушена причинно-следственная связь. HTTPS в действительности шифрует весь обмен, включая тело и заголовки и стартовую строку. Отсутствие HTTPS делает уязвимым для перехвата весь обмен, включая тело, заголовки и стартовую строку. То есть разницу между GET и POST объяснить конфиденциальностью (имею ввиду именно перехват, как в контексте статьи) нельзя даже за уши. А существенная разница как раз в другом.
Выскажу, возможно непопулярную мысль, но список этих вопросов (и ответов тех людей, которые их сформировали на ресурсе www.springboottutorial.com) с большей вероятностью создадут больше путаницы и недопонимания между различными группами людей, прочитав данную статью (опытные специалисты, новички, HR, начинающие PM, и др.)

Первое что бросается в глаза — это сам ресурс. Он спроектирован по большей части как рекламная площадка для сайта с курсами с сайта in28minutes[com], где все статьи специально сделаны так, чтобы привлечь внимание.
[2 бесплатных руководства по прохождению интервью, 90% скидка для нашего курса]

На сайте я нашел в основном статьи с заголовками «10 шагов для изучения технологии/фреймворка X», а также списки с публичными репозиториями других людей на Github, где авторы, не сильно вдаваясь в код и технические подробности, при помощи пары фраз объясняют как это все запустить и что с чем связано.

Также я не вижу, чтобы на вопросы из списка был дан прямой и ясный ответ по сути этого вопроса.
Некоторые ответы на вопросы состоят из одного предложения из которого ответ не является хоть отдаленно полным. (особенно это касается 16 вопроса).

Не знаю откуда авторы данного текста составили этот список вопросов, но неужели в отдельно взятой стране этого действительно достаточно для того, чтобы стать начинающим веб-разработчиком с навыками Spring?

Считаю что данный материал явно не выполняет то, что обещает:
Этот небольшой список вопросов даст вам понимание самых важных концепций Spring, а так же поможет подготовиться к собеседованию
Считаю что данный материал явно не выполняет то, что обещает:

Согласен, ответы местами так себе.
Мне вот нравится список самих вопросов.
Для разминки на собеседовании самое то
В том то и недостаток таких списков, что все их заучивают) И не понимают. Гораздо веселее решать практические задачки по Spring вместе с кандидатом на компьютере.
Это хорошо для начала. После этого я бы спросил например о cycle dependency что нибудь. ConditionalOn-Property/Class и т.п. с интересным примером. Как spring-managed bean получить без Autowire/Inject (ну и отличия этой пары, кстати). Потом можно попросить объяснить на примере как бы человек сделал что-то типа @EnableMyCoolFeature, по типу сприг-бут.
Это на какую позицию?

Как spring-managed bean получить без Autowire/Inject (ну и отличия этой пары, кстати).

Через ApplicationContext считается?

Про последний вопрос — насколько это вообще применимо в контексте обычной разработки?

Это на какую позицию?

Dushnila+

👍👍👍👍

19 Какая минимальная версия Java поддерживается в Spring Boot 2 и Spring 5?
Spring 5.0 и Spring Boot 2.0 поддерживают Java 8 и более поздней версии.

Да ладно? Почему-то на start.spring.io можно без проблем выбрать Spring Boot 2.0.0 и Java 7, при этом всё вполне себе будет работать.

Конечно, я не считаю, что есть хоть какой-то смысл создавать новый проект на второй версии Spring Boot и при этом использовать Java 7, но либо вопрос некорректен, либо Вы просто не удосужились найти правдивую информацию.
У них в доках так написано
Потому что в Spring 5.0 и Spring Boot 2.0 под капотом много где lambda и API из java 8 используются. Попробуйте собрать проект с animal sniffer и указать jdk 7 ;-)
и ни слова о главном отличии Component от Service — в случае автопрокси, компоненты не проксятся по умолчанию.

считаю, еще очень важен вопрос «когда не стоит использовать спринг?»

Ответы на почти все эти вопросы гуглятся за пару минут. Потому что являются частными случаями или ответами на вопрос "а на какие кнопки нужно нажать, чтобы во фреймворке Х сделать всем известную и понятную вещь У". Подобное действительно ещё спрашивают?

Нет смысла спрашивать что-то сложное, не спросив сначала легкое
Посыл моего комментария был чуть другой: зачем задавать подобные вопросы? Что они расскажут о кандидате? Вот, допустим, человек не знает отличие @RestController от Controller, почему существуют Service, Component и Repository. И что нового в Spring 5.0. Действительно ли с подобным соискателем не стоит продолжать дальнейший разговор?
Лично я, чтобы оставить хорошее впечатление о компании продолжил бы, но углубляться в этой тематике не стал…
Считайте это что-то вроде устной задачи fizz buzz по спрингу.
Если компания важно знание и в других областях, я бы советовал начинать тоже с простых вопросов.
Если унижать собеседуемого супер сложными вопросами. То у компании появится плохая репутация
не знает отличие @RestController от Controller

И правда, зачем это знать-то? Код ведь работает


@RestController
public class MyRestController {
    @Autowired
    private MyService myService;

    @GetMapping(value = "...", produces = "application/json")
    public ResponseEntity<MyModel> getMyModel(@PathVariable String code) {
        MyModel myModel = myService.getByCode(code);
        if (MyModel == null) {
            return ResponseEntity.notFound().build();
        }
        return ResponseEntity.status(HttpStatus.OK).
                contentType(MediaType.APPLICATION_JSON).
                body(myModel);

    }
}
Вы с какой целью отвечаете, похоливарить или таки конструктивно?
Sign up to leave a comment.

Articles

Change theme settings