Как запретить кеширование данных, полученных через API?

N, это как раз не проблема и вполне реализуемо, проблема втом как при этом защитить данные от копирования

Как запретить кеширование данных, полученных через API?

Если без CEO то вариантов много, но с CEO вообще нет вариантов(

Как запретить кеширование данных, полученных через API?

N, при этом надо соблюсти прозрачность для CEO?

Как запретить кеширование данных, полученных через API?

N, раз в сутки еще терпимо. Ведь даже если будут "кэшировать" все равно зависимость от пуповины (вашего сервиса) никуда не денется. При этом даже если ваши клиенты программеры и будут честны, никто не даст гарантии что их клиенты не напишут парсер уже с их сайта. А по сему вопросы:
- о распространении какой информации идет речь (хотя бы в общих чертах)?
- насколько критично для бизнес плана будет появление в сети обновляемой копии распространяемой инфы скажем недельной свежести? и если критично, то почему?
- возможно ли введение штрафных санкций к тем, у кого слита информация (способы вычислить чью копию слили есть)?
- насколько введение данных санкций на ваш взгляд будет эффективно и почему?

Как запретить кеширование данных, полученных через API?

N, так, подумал вот в каком ключе.
1. мне не хватает информации о том, для чего это вообще надо (как некий абстрактный сервис или по распространяемым данным уже есть конкретика)
2. плясать тут надо не от технической стороны а от рациональной. Объяснение так себе, попробую раскрыть:
- ценность информации не в самой информации а в ее актуальности. т.е. если вы планируете торговать какой либо информацией по подписке через API вашего сервиса или как либо еще, надо защищать не уже проданную информацию, а ее обновления. Другими словами полноценно защищаться от кэширования нет ни смысла ни тех возможности. Лучшая защита это необходимость получения у вас свежей порции актуальной инфы. Отсюда и вопрос из пункта 1. Ответьте на него хотя бы в общих чертах, и можно будет размышлять дальше.

Как запретить кеширование данных, полученных через API?

N, крутится в голове решение, как оформится отпишусь.

Как запретить кеширование данных, полученных через API?

N, программистам для их сервисов так же выдавать разовые токены при каждом их запросе на инфу? для них не будет костылей, просто сгенерированная вами ссылка с токеном которую они отображают на своем сервисе (при каждом запросе от пользователей к их сервису они по апи обращаются к вам за порцией данных, которые и будут содержать новые ссылки с одноразовыми токенами)

Как запретить кеширование данных, полученных через API?

N, почему фиаско, тот же автортудей и литнет книги дают в виде картинок как раз для препятствия копированию и распространению.

Как запретить кеширование данных, полученных через API?

N, ну или рендерить всю инфу в виде картинок на сервере, а клиенту выдавать инфу этими картинками))))

Как запретить кеширование данных, полученных через API?

N, тут соглашусь, если програмист с определенной периодичностью сканит весь сайт на предмет составления слепка всей инфы близкого к актуальному, то от этого защититься почти нереально, особенно если он (программист) делает это через разные IP (прокси) и соблюдает некий временной интервал между запросами. В таком случае разве что сильная капча поможет.

Как запретить кеширование данных, полученных через API?

N, прочтите мой последний коммент

Как запретить кеширование данных, полученных через API?

rPman, N писал:

чтобы в дальнейшем не было возможности, раз сохранив ID'шники авторов, напрямую обращаться к этому методу, минуя метод "получения авторов"...

Таким образом о полном запрете кэшировании речи не идет. А речь идет об одноразовых ссылках.
Соответственно наиболее простым в реализации мне видится такой способ:
1. создается таблица в БД для сохранения токенов и срока их действия, и цели (автор или книга или глава и ее ID) а так же информация о клиенте (в самом простом случае его IP но если делать правильно, то отпечаток клиентского устройства)
2. при генерации страницы с авторами:
- для каждой книги автора генерируется новый одноразовый токен со сроком жизни скажем сутки.
- все ссылки на книгу в текущей генерации страницы автора содержат данный токен (свой для каждой книги)
- в бд вносится токен, дата генерации и цель (автор или книга или глава и ее ID) и отпечаток клиентского устройства
3. с остальными пунктами (книгиб главы) по той же схеме

как это работает:
я захожу на страницу авторов, и все ссылки на книги содержат уникальный одноразовый токен с ограниченным сроком действия, привязанный к данной конкретной записи (автору, книге, главе) а так же привязанный к данному конкретному устройству.
При нажатии на любую ссылку (любого автора) идет запрос на сервер, содержащий и данный токен.
Сервер получая запрос, смотрит в БД наличие данного токена и связанной с ним инфы и если токен есть сравнивает ID автора из ссылки и ID автора взятого из связанной с токеном инфы а так же сравнивает цифровой отпечаток устройства с цифровым отпечатком устройства сохраненном в токене. Если хоть одна из проверок не пройдена, отправляем пользователю страницу "ай-ай-ай)))", если пройдена, выдаем ему список книг автора и удаляем токен из базы. Далее выданный список книг автора работает по той же схеме, и список глав книги тоже. Плюс ко всему раз в N времени подчищаем в базе просроченые токены.
Таким образом по любой из сылок со страницы можно получить информацию только 1 раз, что и требовалось реализовать.

и не дать возможность закэшировать ответ, например, метода "получения книг по автору", чтобы в дальнейшем не было возможности, раз сохранив ID'шники авторов, напрямую обращаться к этому методу, минуя метод "получения авторов"...

Как запретить кеширование данных, полученных через API?

rPman, ну, тут на самом деле много нюансов. Если токен менять скажем раз в минуту, то злоумышленнику придется и ссылки на книги раскиданные по инету менять раз в минуту. Это в принципе реализуемо на его собственных ресурсах, но совсем не реализуемо на ресурсах третьих лиц. При этом не забываем о проверке на сервере с какого домена пришел запрос.

Как запретить кеширование данных, полученных через API?

rPman, не, токен надо менять, иначе что помешает мне открыть в селениуме страницу авторов навсегда и раздать ссылки с вечнодействующим токеном.

Как запретить кеширование данных, полученных через API?

N, внимательно прочтите

спойлер

...обновляйте его если страница с авторами открыта раз в минуту...

Не в зависимости от моего сообщения бот бы сначала писал шаблон. Как?

Вы случайно не Александр Чуприн?

Можно ли получить данные от Api не дожидаясь полной загрузки?

Алексей Ярков, сижу уже неделю жду ответа от возможного работодателя

чат

Я: В какие примерно сроки принимается решение по результатам выполнения тестового задания (несколько часов, дней, более длительный срок)?

Кадровик: Ответ обычно около недели, сейчас большая загруженность. Но вы пишите если вдруг мы не выйдем на связь.

Я: Виктория, доброе утро.
Неделя прошла, напоминаю о себе)

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

Можно ли получить данные от Api не дожидаясь полной загрузки?

Алексей Ярков, Mdmitr, почему никак, очень даже как)))
делаете свой промежуточный сервер, который получая запросы от клиента, на низком уровне (уровень соединения tcp/ip) перенаправляет запрос на нужный сервер, читая его ответ из сокета частями по мере загрузки. Для этого вам понадобится реализовать поверх голого tcp/ip соединения поддержку протокола http/https со всеми хеадерами и прочим, а так же хитрый парсер для получаемых данных, способный выковыривать самодостаточные куски json-а по некоторому признаку.
НО!!! хоть это теоретически и возможно, такое решение будет дичайшим костылем (ктото возможно назовет его микросервисом ))))))

Как сделать изменяемый контент при переключении тарифа?

1VAAS1, ну так то да, запрос должен был быть таким "пушной, что волнует народ")))

Как в CSS сделать такую кнопку?

Пашенька, можно и без оферфлоу, но радиус закругления подобрать трудно, да и прямо таки аналогичного результата не добиться (наверное))))