Согласно https://datatracker.ietf.org/doc/html/rfc3986 в адресе допустимы только ASCII символы и то не все. Просто некоторые браузеры (и серверный софт) строго поддерживают стандарты, а некоторые допускают вольности для удобства пользователя, надеясь что по пути не будет прокси, который выкинет запрос как не валидный

P.S. Про https://tools.ietf.org/html/rfc3987 я в курсе

А может не готовы жертвовать удобством ради, например, большей скорости загрузки страниц — в их метриках удобства она имеет минимальный вес

У некоторых внутреннее табу на использование неймспейсов и ко на кластере для разделения дев/тест окружений от прода

Скорее это разные контексты предметной области типа производства метизделий.

А теперь композер основное средство распространения. Но теперь Октобер закрыл код и особого значения это уже не имеет для меня — инициирую отказ от Октобера в пользу хотя бы Laravel

• WP — открытый (GPLv2+) и бесплатный, October 2+ — закрытый и платный. Инициирую отказ от него в компании

Переписывать можно по частям, одновременно работая в двух системах, маршрутизируя запросы юзеров между ними

Так уж рыночек порешал, что есть позиции DevOps-инженеров, основная задача которых в идеальном мире — технически обеспечивать работу по методологии

Это смотря какие "мы", на каком уровне "мы" и тп. Жизнь "нас", команды разработчиков какого-то модуля монолита, часто становится проще, если принято решение вынести его в микросервис. По крайней мере никто не завяжется на наши детали реализации: вот наш ендпоинт, вот его контракт, вот даже клиентская библиотека, и больше у вас ничего нет физически.

А другие приложения бездумно обновляли версию этого пакета?

Отдать на аутсорс всякое не особо на старте важное, но необходимое?

Ну а как научиться, не начав делая их неправильно? ))

Тут ещё конфликт интересов может быть почти всегда есть на разных уровнях Кому-то интересно попробовать в проде новый технологии и подходы, кому-то наоборот неохота изучать что-то новое и переделывать на него без явной необходимости. Даже у бизнеса бывает мнения типа "если мы не будем использовать стандарты де-факто типа кубернетес, то не получим инвестиции на рост"

ни разные версии одного и того же API — это противоестественно(хотя и возможно).

Да вполне естественно, когда в новую версию API добавили нужную фичу, при этом сильно изменив и всё остальное типа протокола или формата, а времени переписывать весь клиентский код сразу нет. "работает — не трогай" — вполне естественно. Вот и появляются в коде других микросервисов и пользовательских приложений ServiceAClientV1, ServiceAClientV2 которые для разных частей одного инстанса обращаются к другому инстансу по разным версиям API. И это может длиться годами пока команда сервиса A не продвинет выделение времени другим командам для выпиливания ServiceAClientV1 из кодовой базы других команд, потому что все время в А уходит на согласованную поддержку двух версий

Одновременно раные версии одной библиотеки в рамках одной сборки не используются

Привет от экосистемы nodejs

Думаете тимлид сроки назначает?

«Пока ты тут будешь свой код рефакторить — конкуренты выкатывают новые фичи»

Если не отрефакторим, то фичи мы будем выкатывать медленнее конкурентов — они явно времени на рефакторинг не жалеют )

«Зачем тебе рефакторить? Ты плохой программист и написал говнокод?»

Ты плохой постановщик и 5 лет назад описал только 5 фич, а сейчас жалуешься, что 100500-ю никак закончить не можем без багов — надо было сразу все 100500 описать ))

В теле ответа могут быть:

• обогащенное мета-информацией тело запроса (created_at, created_by)
• сообщения об ошибках
• id транзакции
• ...