Следующий вопрос касается структуры кэширования, которая должна быть реализована или уже существует для поведения, основанного на REST, описанного ниже.
Цель состоит в том, чтобы запросы GET и HEAD обрабатывались так же эффективнокак запросы к статическим страницам.
С точки зрения технологии, я думаю о Java-сервлетах и MySQL для реализации сайта.(Но появление веских причин все еще может повлиять на мой выбор технологии.)
Веб-страницы должны поддерживать GET, HEAD и POST;GET и HEAD были намного чаще, чем POST.Содержание страницы не изменится с GET / HEAD, только с POST.Поэтому я хочу обслуживать запросы GET и HEAD непосредственно из файловой системы и только запросы POST от сервлета.
- Первая (слегка неполная) идея состоит в том, что запрос POST будет предварительно вычислять HTMLдля последующих запросов GET / HEAD и сохраните их в файловой системе.Тогда GET / HEAD всегда получит файл оттуда.Я полагаю, что это легко может быть реализовано в Apache с условной перезаписью URL.
- Более изощренный подход заключается в том, что GET будет обслуживать HTML из файловой системы (и HEAD использует его тоже), если предварительно-computed файл, и в противном случае вызовет механизм сервлета для генерации его на лету.В этом случае POST не будет генерировать какой-либо HTML, а только соответствующим образом обновит базу данных и удалит HTML-файл из файловой системы в качестве флага, чтобы он был сгенерирован заново со следующим GET / HEAD.Преимущество этого второго подхода состоит в том, что он более изящно обрабатывает «начальную фазу» веб-страниц, где еще не был вызван POST.Я считаю, что этот подход с отложенным генерированием и хранением может быть реализован в Apache, предоставляя обработчик ошибок, который будет вызывать сервлет в случае «файл не найден, но должен быть там».
В последующем цикле уточнения для экономии пропускной способности кэшированные файлы HTML также должны быть доступны в версии gzip-ed, которая подается, когда клиент это понимает.Я считаю, что основные механизмы должны быть такими же, как и для несжатых файлов HTML.
Поскольку таких REST-подобных страниц будет много, для обоих подходов иногда может потребоваться какой-то механизм для сбора мусора редко используемых файлов HTML вЧтобы сэкономить файловое пространство.
Подводя итог, я уверен, что моя оптимизированная для GET / HEAD архитектура может быть реализована без ошибок.Во-первых, я хотел бы получить мнение об этой идее (я думаю, что это хорошо, но я могу ошибаться) и о том, есть ли у кого-то уже опыт работы с такой архитектурой, возможно, даже он знает о свободной платформе, реализующей ее.
Наконец, я хотел бы отметить, что клиентское кэширование - это не решение, к которому я стремлюсь, потому что несколько разных клиентов будут ПОЛУЧИТЬ или ГОЛОВАТЬ одну и ту же страницу.Более того, я хочу полностью избежать механизма сервлетов во время запросов GET / HEAD в случае, если предварительно вычисленный файл существует.Его даже не следует вызывать для предоставления HTTP-заголовков, связанных с кэшем, в запросах GET / HEAD или для вывода файла на вывод.
Вопросы:
- Есть ли лучше (стандартнее)механизмы, доступные для достижения цели, указанной в начале?
- Если нет, кто-нибудь знает о существующей платформе, подобной той, которую я рассматриваю?
Я думаю, что кеш HTTP недостичь моей цели.Насколько я понимаю, кэш HTTP все равно должен вызывать сервлет с запросом HEAD, чтобы узнать, изменил ли POST тем временем страницу.Поскольку изменения страницы происходят в непредсказуемые моменты времени, заголовок HTTP, указывающий время истечения, недостаточно хорош.