Комментарии 28
28 Почему для конфиденциальных данных рекомендуется использовать POST, а не GET запросы?
Странный ответ, учитывая, что если у нас HTTP, то и GET и POST отправляются открытым текстом, а при HTTPS у нас шифруется соединение полностью, в том числе и url.
29 Можно ли передать в запросе один и тот же параметр несколько раз?
Да, можно принять все значения, используя массив в методе контроллера
Насколько я помню, можно в качестве аргумента использовать любую подходящую коллекцию: List, Set
Странный ответ, учитывая, что если у нас HTTP, то и GET и POST отправляются открытым текстом, а при HTTPS у нас шифруется соединение полностью, в том числе и url.
Теоретически можно из истории гет-параметры вытащить можно (и при xss есть какие-то шансы), в то время как post-параметры вытащить скриптом не удастся.
"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.
Видимо автор оригинального поста поленился разобраться и надергал по паре предложений из гугла.
Ответ ещё страннее, учитывая что GET запросом можно точно так же body передавать.
Это считается антипаттерном и некоторые REST-клиенты (постман вроде) не разрешают body в GET, но тем не менее разница между GET и POST вкладывается человеком, а никак не протоколом.
28 неверный ответ, опасный даже. без шифрования промежуточные узлы могут прочитать и тело и адрес. С шифрованием не прочитать ни тело ни адрес запроса. А GET/POST история совсем другая. История браузера, глаза соседа, случайное копирование из адресной строки, кеширование, идемпотентность.
Первое что бросается в глаза — это сам ресурс. Он спроектирован по большей части как рекламная площадка для сайта с курсами с сайта in28minutes[com], где все статьи специально сделаны так, чтобы привлечь внимание.
[2 бесплатных руководства по прохождению интервью, 90% скидка для нашего курса]
На сайте я нашел в основном статьи с заголовками «10 шагов для изучения технологии/фреймворка X», а также списки с публичными репозиториями других людей на Github, где авторы, не сильно вдаваясь в код и технические подробности, при помощи пары фраз объясняют как это все запустить и что с чем связано.
Также я не вижу, чтобы на вопросы из списка был дан прямой и ясный ответ по сути этого вопроса.
Некоторые ответы на вопросы состоят из одного предложения из которого ответ не является хоть отдаленно полным. (особенно это касается 16 вопроса).
Не знаю откуда авторы данного текста составили этот список вопросов, но неужели в отдельно взятой стране этого действительно достаточно для того, чтобы стать начинающим веб-разработчиком с навыками Spring?
Считаю что данный материал явно не выполняет то, что обещает:
Этот небольшой список вопросов даст вам понимание самых важных концепций Spring, а так же поможет подготовиться к собеседованию
Считаю что данный материал явно не выполняет то, что обещает:
Согласен, ответы местами так себе.
Мне вот нравится список самих вопросов.
Для разминки на собеседовании самое то
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, но либо вопрос некорректен, либо Вы просто не удосужились найти правдивую информацию.
Ответы на почти все эти вопросы гуглятся за пару минут. Потому что являются частными случаями или ответами на вопрос "а на какие кнопки нужно нажать, чтобы во фреймворке Х сделать всем известную и понятную вещь У". Подобное действительно ещё спрашивают?
Считайте это что-то вроде устной задачи 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);
}
}
Spring: вопросы к собеседованию