Senior Java Developer в EPAM
  • Повний огляд REST: нюанси, поради, приклади

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

  • Повний огляд REST: нюанси, поради, приклади

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

    Підтримав: Taras Terletsky
  • Повний огляд REST: нюанси, поради, приклади

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

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

    Підтримав: Олександр Мощенко
  • Повний огляд REST: нюанси, поради, приклади

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

  • Повний огляд REST: нюанси, поради, приклади

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

  • Повний огляд REST: нюанси, поради, приклади

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

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

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

  • Повний огляд REST: нюанси, поради, приклади

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

  • Повний огляд REST: нюанси, поради, приклади

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

  • Повний огляд REST: нюанси, поради, приклади

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

  • Повний огляд REST: нюанси, поради, приклади

    Дякую!

    Підтримав: Nazar Kostetskyi
  • Повний огляд REST: нюанси, поради, приклади

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

    Підтримали: Oksana Masalitina, Mykhailo Hnap
  • Як влаштована робота з памʼяттю в Java

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

  • Як влаштована робота з памʼяттю в Java

    Дуже дякую за коментар, дійсно про стек малувато інформації, думаю, доповню цей розділ з часом.

  • Як влаштована робота з памʼяттю в Java

    Ну тоді не підкажу, не зустрічав використання слабких посилань на практиці деінде окрім кешів

  • Як влаштована робота з памʼяттю в Java

    Мабуть пропустив, дякую

  • Як влаштована робота з памʼяттю в Java

    Глянув на цей

    caffeine

    (com.github.ben-manes.caffeine) З того що я побачив, це просто реалізація кешів для різних потреб/фраємворків за допомогою різнотипних мап, і саме WeakReference i WeakHashMap я там не побачив) Тобто це просто більш формалізований спосіб використання кешів, але так як WeakHashMap він не використовує, я підозрюю, що працює він нічим не краще ніж реалізація за допомогою WeakReference i WeakHashMap, просто зручніше, але щей додаткову залежність варто додавати в проект і GC не підчищатиме при кожній збірці сміття, бо є міцні посилання(

  • Як влаштована робота з памʼяттю в Java

    Дуже дякую за питання, це мені дозволяє краще розуміти аудиторію і те що їм незрозуміло/не вистачає інформації. Коротко про випадки, де WeakReference може бути корисним:
    1. Мапи з слабкими ключами, які можуть бути зібрані сміттям
    Іноді буває корисно створювати мапи, де ключі або значення можуть бути зібрані сміттям, якщо на них більше немає сильних посилань. Для цього існують спеціальні класи WeakHashMap, які використовують слабкі посилання на ключі. Це особливо корисно для зберігання метаданих об’єктів і це є одним з прикладів кешування.

    2. Реалізація ідентичних об’єктів (Canonicalizing Maps)
    Коли у вас є багато об’єктів, які мають однаковий стан (наприклад, рядки), слабкі посилання можуть допомогти уникнути дублювання, дозволяючи створювати єдині екземпляри (канонічні представники). Це може зекономити пам’ять і зменшити навантаження на систему. Таким чином їх зручно використовувати у парі з патерном Flyweight.

    3. Інтеграція з бібліотеками та фреймворками
    Деякі фреймворки використовують слабкі посилання для збереження внутрішніх об’єктів. Наприклад, Hibernate може використовувати слабкі посилання для кешування ентіті, щоб вони могли бути зібрані GC, коли вони більше не потрібні.

    4. Реалізація слабо зв’язаних компонентів (Weakly Referenced Components)
    Коли компоненти не повинні перешкоджати звільненню пам’яті, слабкі посилання можуть бути використані для уникнення утримання зайвої пам’яті. Це може бути корисним у складних системах, де багато компонентів взаємодіють один з одним.

    5. Використання у великих системах зі складною пам’яттю
    У великих і складних системах, де є багато взаємозв’язків між об’єктами, слабкі посилання можуть допомогти уникнути циклічних посилань, які можуть заважати збирачу сміття.
    Якщо щось забув, то сподіваюсь, що хтось доповнить)

  • Як влаштована робота з памʼяттю в Java

    Ну чому не треба, це просто штука, яку ти не часто будеш використовувати. А на рахунок переписали, бо не розібрались, щось мені підказує, що просто було лінь розбиратись, бо це не якийсь rocket science) Загалом штука прикольна і часом корисна. Так само в JDK є WeakHashMap, яка якраз використовує WeakReference як ключі, не всі за нього чули і ще менше використовували, а вона в JDK присутня, я думаю, що Oracle за стільки років розвитку джави вже би давно деприкейтнули те, що нікому не потрібно))

  • Як влаштована робота з памʼяттю в Java

    Дякую за зауваження. Обовʼязково підправлю!

  • Як влаштована робота з памʼяттю в Java

    G1GC цілком добре виконує свою роботу. Інші збирачі сміття мають як переваги так і недоліки, для збирача сміття за замовчуванням він підходить, все залежить від специфіки роботи, не кожен застосунок треба тюнити або використовувати інший GC, Oracle старається зробити найбільш підходящий для більшості застосунків GC основним, але також і додає/оптимізовує інші, щоб дати можливість застосункам які потребують більш особливих налаштувань все натюнити під себе, але для цього вже важливе глибоке розуміння їх роботи. Ця стаття покликана показати як працює G1GC, модель памʼяті JVM та трохи розповісти про інші GC, цього мало аби ідеально володіти знанням та розумінням всіх збирачів сміття. Можливо в майбутньому я допишу цю статтю або створю нову, яка вже буде стосуватися суто збирачів сміття.

← Сtrl 12 Ctrl →