Здравствуйте, Sinclair, Вы писали:

S>2. Делаем два ресурса: "анонимизированное постановление", "полноценное постановление". Анонимный доступ ко второму получает 401, аутентифицированный доступ без прав на данное дело получает 403.

А если у тебя десять независимых полей в ресурсе? Будешь делать 100 ресурсов? Сильно сомневаюсь что это хорошее решение, их же придется потом тестировать.

S>3. Делаем два ресурса: постановление, в "тексте" которого есть ссылки на фигурантов, каждый из которых — самостоятельный ресурс. Постановления отдаём всем желающим, детали фигурантов — только авторизованным пользователям. Остальные получают 403.

Опять же, ИБ не велит) Как только у атакующего появляется возможность идентифицировать анонимизированые ресурсы, деанонимизация становится делом техники.

S>Можно ссылку на источник, который вы цитируете? Я не эксперт по ИБ, с удовольствием ознакомлюсь.

Можно, например, начать с википедии и заполировать OWASP Developer Guide. Современный подход к ИБ построен на модели швейцарского сыра: вместо того чтобы обеспечивать безопасность только в одном слое, мы реализуем достаточный уровень безопасности на каждом слое. Один из аспектов такого подхода это принцип минимальных привилегий (пользователю или сервису выдаются как можно меньшие права на как можно более короткий срок достаточный для выполнения операции) и принцип разделения (пользователю выдается только та информация, которая необходима для выполнения операции). И нет, это не security by obscutiry, потому что безопасность на слое ресурсов никак не отменяет проверки прав на уровне сервисов, а лишь дополняет их. Короче, если ты все еще занимаешься разработкой и тем более принятием архитектурных решений, рекомендую пройти какой-нибудь хороший AppSec тренинг, а то с твоего детства многое изменилось )

S>Я не понимаю, что вы имеете под пунктом а). Да, совершенно верно, причин ошибки много, и их надо обрабатывать. В любом случае.

В времена Нового Царства, каждый египтянин после смерти подвергался суду Осириса, где он должен был долго и нужно перечислять чего в жизни он НЕ делал. Вот и с ошибками та же история ) Позитивный сценарий может завершиться только одним способом, негативный -- бесконечным множеством способов из которых восстановимых считанные единицы: 502, да 401 и то не всегда.

S>Во-вторых, что такое "указатель"? Я так понял, вы положились на то, что все исходные данные загружены в память вашей единственной машины?

Не обязательно, любой идентификатор объекта. Хотя, конечно, кэши на разделяемой памяти выгладят красиво.

S>Всё верно. Только это хранение вы реализуете не за счёт своих средств, дорогостоящих и ограниченных, а за счёт средств клиентов, которые масштабируются автоматически и бесплатно.

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

S>И только "табличные данные", которые являются частным случаем ровно той же задачи, до сих пор реализуются методиками девяностых годов прошлого века. Нет никакой причины так делать, кроме "здесь так принято" и "мне лень думать, как сделать нормально".

Вообще говоря, в 25 году мало кто работает с табличными данными вообще. Сейчас в моде разделяемое состояние между сервером и клиентом и реактивное программирование для двусторонней синхронизации этой модели в реальном времени. Если непонятно сформулировал, посмотри на фейсбук.

S>Этот "контракт" невозможно надёжно обеспечить в реальной среде. Всё, что можно делать — это притворяться, что он выполняется. Поэтому существенной разницы между hateoas и "компактной" формой ресурсов с точки зрения достигнутого результата я не вижу.

Так практически вся микросервисная архитектура это история не про гарантии, а про достаточно хорошие допущения.