Из вашего описания я считаю, что вы можете подвергнуться риску преждевременной оптимизации, именно здесь вы тратите много времени, беспокоясь о чем-то, что не имеет значения. Хуже всего то, что оптимизация памяти или процессора, как правило, снижает читабельность, что может значительно облегчить появление ошибок. Поэтому оптимизация памяти или процессора - это то, что вам следует делать, только если у вас есть очевидная проблема, и профилировщик показал, что эта область является root проблемы (профилировщик памяти или процессора в зависимости от ситуации)
Примите В вашем примере вы обеспокоены тем, что каждый запрос генерирует список (предположительно, Arraylist?). Это небольшие структуры данных сами по себе (вероятно, небольшой процент от общего объема используемой вами памяти), они становятся большими только тогда, когда содержат большое количество других больших объектов, хуже, если вы предлагаете сбросить список и использовать его повторно между запросами API. Такое повторное использование и сброс списка может привести к появлению тонкой ошибки, которая может возникать только периодически (наихудшая ошибка); если два запроса API перекрываются (весьма вероятно для веб-сервера), то оба они будут использовать список одновременно; состояние из запроса A может просочиться в B или наоборот. Это почти идеальный пример того, почему вы не должны преждевременно оптимизировать.
(Если список содержал данные c, которые никогда не менялись, мой ответ мог бы быть другим)