Дякую за уважність, підправив.

Згоден. Нащо лізти в те, що і так працює)

Саме так

Якщо ви про Epsilon GC, то його варто використовувати лише для тестування застосунку без впливу збирача сміття, навіть CMS депрікейтнули через те, що він не робив дефрагментацію ганяючись за продуктивністю і малими паузами. Тому якщо є потреба, то підбирайте збирач сміття під проект, без нього не стартуйте, бо забʼється памʼять з часом і все повалиться. Гляньте мою статтю саме по збирачах сміття, посилання на неї є на початку цієї статті.

Я б так не сказав, українське джава комʼюніті тільки росте. Може ви не там шукаєте) Гляньте @ukraine_java i @professional_software_wizard в телеграмі

Стаття вийшла доволі обширною, тому було прийнято рішення розділити її на декілька частин, результати продуктивності та тюнінг буде в наступній частині

Так з цього треба було починати)

Схоже тут я все таки помилився, G1GC досі збирач сміття за замовчуванням, ZGC просто тепер за замовчуванням Generational. Різні вендори можуть ставити різні дефолтні конфіги, тільки що перевірив на версії Oracle-23.0.2 G1GC дефолтний. Для Temurin-23.0.2 знову ж таки G1GC. Спробуйте перевірити саме jdk, не використовуючи докер.

Якщо alias-ids правильно впроваджені (без прив’язки до чутливих даних), їх використання в URL для RESTful API є хорошою практикою. Ви можете реалізувати як POST /transfers/{alias-id-1}/{alias-id-2}, так і POST /transfers із передачею alias-ids у тілі запиту, залежно від того, що більше відповідає вашій архітектурі. Але для максимальної безпеки краще залишати ідентифікатори в тілі запиту, особливо якщо мова йде про чутливі операції, як-от фінансові транзакції.
Але я би все таки радив робити через request body, як мінімум щоб не роздувати url та збільшити секʼюрність.

Краще не вказувати ці дані як path variables в url для більшої секʼюрності, безпечніше буде передавати через request body

Я ще часто використовую/стикаюся з
201 — все добре, ресурс створено
204 — все окей, але ніц не знайдено
405 — не той метод, дурнику
409 — назріває конфлікт, треба шось міняти
415 — що це за тип даних, мені таке не треба
)))

Але й інші можуть знадобитися/трапитися, просто набагато рідше)

Дякую за активність, це мене мотивує писати далі, дуже радий, що контент був корисним!

По хедерах в записці прикріпленій до голубів)

Дійсно, сам REST є архітектурним стилем і не прив’язаний виключно до HTTP.

REST можна використовувати з будь-яким протоколом, але він часто реалізується через HTTP, оскільки це найпоширеніший протокол для веб-додатків. У дисертації Роя Філдінга не йдеться конкретно про HTTP-методи, але ми говоримо не суто про дисертацію, а про те, що можна застосувати в реальному житті. Філдінг описує REST як архітектурний стиль, що базується на принципах взаємодії між компонентами через стандартизовані інтерфейси та гіпермедіа.

HTTP в цьому контексті просто виступає як реалізація принципів REST, — це загальноприйнята практика для веб-розробки.

Тепер можна буде і українською нагуглити, шей швидше 5 хв і більше деталей.
Якщо б я розписував абсолютно всі нюанси з прикладами, то це була б книжка, а не стаття. Якщо переваги та недоліки REST незрозумілі з контексту, то я можу додати окремий розділ, те ж саме про приклади, але я вважаю, що достатньо зрозуміло пояснив, чисто субʼєктивна думка.

А яким чином це суперечить принципам REST? Це просто поради як спростити собі та іншим життя при роботі з REST, загальноприйняті норми, але не обовʼязкові умови.

Схоже на доу відображається суто символ, а код символа трансформується в символ, гляну як можна виправити, дякую за уважність!)

Дякую!

В мене якраз була мета зібрати максимум корисної інформації в одному місці і все зрозуміло пояснити, щоб кожен міг не тільки прочитати і шось корисне для себе взяти, а й використати як шпаргалку/довідник при потребі.

Я не намагався описати роботу всіх GC, а просто показати як працює дефолтний і коротко розказати про декілька інших. Якщо описувати детально всі GC їхню роботу, специфіку і ще більше заглиблюватись в роботу з памʼяттю, то це вже буде не стаття, а ціла книжка)
А на рахунок термінології гарне зауваження, але я не думаю, що це критично;)