ого, не думал что все так сильно, но личная неприязнь некоторых спикиров вполне может присутствовать. Но всегда можно сделать свою конференцию без статических методов и с правильными объектами

ну, никого нельзя преследовать за инакомыслие, но коль конфа дело частное, имеют право отказать

Так уже сделал и провёл https://www.iccq.ru/2021.html

как и некоторые люди имеют право не поддержать конфу рублем

мне всегда максимально нравится дизайн сайтов Егора

Кто хорошо разбирается можете помочь с одной функцией?

Господа сенсеи. Вопрос. У меня есть класс контроллер, в нем метод https://pastebin.com/g3bp1A3G.
Потом я этот метод тестирую https://pastebin.com/NMfKtsHS . какой параметр я могу ожидать в andExpect(), если мне нужно что-то типа Instance of collection type??

jsonPath, и hamcrest collection matched

С точки зрения дизайна RESTful API как правильнее передавать настройки представления ресурса и токен доступа?

К чему я пришёл после изучения статей:

Настройки представления в виде параметров запроса:
api/v1/items/1
api/v1/items/1?fields=all
api/v1/items/1?fields=name,date,images

Jwt токен доступа в заголовке:
Authorization: Bearer <token>

В то же время, например, vk api даже токен принимает в параметрах запроса


1. Это лучшая практика? Видел мнение, что настраивать представление ресурса следует через заголовок "Accept":
https://stackoverflow.com/a/7853235


2. Если для настройки представления использовать параметры запроса, то по умолчанию лучше выдавать лёгкий или полный объект?


3. Что ещё лучше передавать в параметрах, а что в заголовках? В чём глобальная логика? Как я понял, параметры должны специфицировать получаемую информацию (представление), а заголовки передают любую метаинформацию для обслуживания запроса: токен, ожидаемый / передаваемый формат, и тд

кмк токен в заголовке, а передавать список полей, которые надо отдать - ну такое. зачем оно? если прям надо - сделай пару-тройку разных наборов, соответственное количество ДТО и вперед. тип дто либо параметром, либо в пути
api/v1/items/1/full
api/v1/items/1/small
api/v1/items/1/preview

Лёгкое представление нужно для того, чтобы не передавать встроенные в сущность листы, если они не нужны

а Accept не перегружай, там должна быть только информация о формате, xml/json/etc

так сделай несколько ДТО, соответственно несколько разных типов представления

api/v1/items/1/full
api/v1/items/1/small
api/v1/items/1/preview

это не REST, это просто RPC
В REST у ресурса должен быть строго один адрес, по которому мы получаем, модифицируем или удаляем ресурс

Дело не в DTO, их сделать не проблема. Я про то, как правильно готовить REST

это демагогия, ну сделай праметром
api/v1/items/1?view=full|small|preview

@lex_it, сделать можно что угодно, надо ещё чтобы это было правильно, или хотя бы осмысленно. Я предпочитаю, если позволяют условия, сперва искать лучшие практики для всего что делаю)

ну передача списка полей или типа ДТО уже нарушение принципов rest, так что либо крестик снимай, либо трусы натягивай

С чего бы это не rest?