Я думал о пакетных чтениях и записи в среде RESTful, и я думаю, что пришел к пониманию, что у меня есть более широкие вопросы о кешировании HTTP. (Ниже я использую запятые ( "," ), чтобы разграничить несколько идентификаторов записи, но эта деталь не относится к обсуждению.)
Я начал с этой проблемы:
1. Единый GET
недействительный пакетным обновлением
GET /farms/123 # get info about Old MacDonald Farm
PUT /farms/123,234,345 # update info on Old MacDonald Farm and some others
GET /farms/123
Как сервер кэширования между клиентом и сервером Farms знает, чтобы аннулировать его кеш /farms/123
, когда он видит PUT
?
Тогда я понял, что это тоже проблема:
2. Пакет GET
недействителен с помощью однократного (или пакетного) обновления
GET /farms/123,234,345 # get info about a few farms
PUT /farms/123 # update Old MacDonald Farm
GET /farms/123,234,345
Как известно кешу об аннулировании многоуровневого GET
, когда он видит, что PUT идет?
Итак, я понял, что проблема была действительно просто с пакетными операциями. Тогда я понял, что любая связь может вызвать подобную проблему. Пусть говорят, что у фермы есть нуль или один владелец, а владелец может иметь нуль или одну ферму.
3. Единый GET
недействителен обновлением соответствующей записи
GET /farms/123 # get info about Old MacDonald Farm
PUT /farmers/987 # Old MacDonald sells his farm and buys another one
GET /farms/123
Как кеш знает, чтобы сделать недействительным одно GET, когда видит PUT??
Даже если вы измените модели на более RESTful, используя модели отношений, вы получите ту же проблему:
GET /farms/123 # get info about Old MacDonald Farm
DELETE /farm_ownerships/456 # Old MacDonald sells his farm...
POST /farm_ownerships # and buys another one
GET /farms/123
В обеих версиях # 3 первый GET должен вернуть что-то вроде (в JSON):
farm: {
id: 123,
name: "Shady Acres",
size: "60 acres",
farmer_id: 987
}
И второй GET должен вернуть что-то вроде:
farm: {
id: 123,
name: "Shady Acres",
size: "60 acres",
farmer_id: null
}
Но это не может! Даже если вы используете ETag
соответствующим образом. Вы не можете ожидать, что сервер кэширования проверит содержимое для ETag
- содержимое может быть зашифровано. И вы не можете ожидать, что сервер уведомит кэши, что записи должны быть недействительными - кэши не регистрируются на серверах.
Так есть ли заголовки, которые мне не хватает? Вещи, указывающие на кеш, должны делать HEAD
перед любым GET
для определенных ресурсов? Я полагаю, что я мог бы жить с двойными запросами на каждый ресурс, если я могу сказать кэшам, что ресурсы, вероятно, будут часто обновляться.
А как насчет проблемы с одним кешем, получающим PUT
, и зная, как аннулировать его кеш, а другой - не видеть?