estic

Чем "такое" программирование, лучше никакого. Хотя в своей "песочнице" можно играться, сколько угодно. Но зачем эту "песочницу" всем демонстрировать?

Зачем что-то читать, когда можно придумать свой собственный термин? 😀

Хотя, похоже, там более тяжелый случай, чем просто придумывание нового термина взамен имеющегося.

Ну, действительно зачем вы приплели сюда наследование, когда речь о "прототипировании"?

Думаете, что сам автор использовал неверный термин? Тогда нужно четко об этом написать!

Смысл есть. Загрузки могут блокироваться, также как и при отсутствии какого-либо сертификата.

Исключение: хранилище имеет адрес наподобие [https:]//shared1050.storage.ru/estic[/], где estic - "bucket" конкретного пользователя, а домен принадлежит провайдеру. Иногда бывает и так: [https:]//estic.shared1050.storage.ru[/] 😉

Возможно, провайдер сам выпустил сертификат для "делегированного" домена. Проверьте характеристики используемого сертификата.

А с определенного момента вовсе все начнет разваливаться. Такой подход можно использовать для создания прототипа. Развивать практически невозможно, если продолжать использовать те же методы.

Такое ощущение, что автора "забанили в Яндексе".

В программировании прототипирование - это создание прототипа программного продукта (предварительной технической версии). Не путать с MVP. Прототип предназначен для самих разработчиков, он может только демонстрироваться пользователям "на картинке". MVP - готовый программный продукт для пользователей. Это как пилотная серия сериала.

Обычно, когда делегируют на DNS-серверы хостинг-провайдера, прописывать самому A-записи вовсе не нужно. Достаточно создать сайты (хосты, WWW-домены - это другие возможные названия "сайтов"). Но проверить не помешает, что соответствующие ресурсные записи были созданы автоматически и корректны.

Можно было и "прописать A-запись для поддомена  у регистратора домена" (при условии, что вы используете DNS-серверы регистратора для домена 2-го уровня; иначе нужно было прописывать на DNS-серверах одного хостинг-провайдера IP сервера другого хостинг-провайдера).  Вполне нормальный способ, если IP сервера меняется редко. Нормальные провайдеры обычно заранее предупреждают о такой смене (в "переходный период" сайт может работать на любом из двух IP).

В статье по ссылке в общем все верно написано: для бэкэнда PHP/Go. Python на любителя (хотя про Go с его обработкой ошибок можно то же самое сказать 😀). Про Swift ничего не могу сказать, т.к. вообще не используем. "Нода" для тех, кто хочет "везде успеть", но не способен осилить два языка 😊

Писали. Продолжать бессмысленно. Все равно потом последуют вопросы наподобие "А где это?", "А как это?" Все необходимые наставления были даны в теме. Кому нужно, тот воспользуется.

Поэтому я и не стал продолжать этот разговор. Бессмысленно.

Подобными вопросами вы отлично "разгоняете волну" на этом форуме. Так что уже можно прекратить рекламировать другой форум. А то какое-то несоответствие получается 😊

Так то были примеры того, как делать не нужно, если вы не поняли.

В REST вовсе предпочтительно делать так:

DELETE /collection/object