2016-05-25 8 views
0

Предположим, что есть интерфейсный клиент, который разговаривает с задним концом с собственным хранилищем данных. Задний конец возвращает некоторые данные полезной нагрузки, которые использует передний конец для отображения страницы. Вот «типы» поведения, которые я могу подумать, и мои вопросы:Какие типы функциональных возможностей задней части существуют для API?

Как идти и решать, с какой реализацией идти? Каковы соглашения по обратному поведению?

Реализации я могу думать:

  1. Задний конец графиков работы для извлечения данных из внешнего API, обрабатывает важную информацию, и сохраняет его в своем собственном хранилище данных. Когда передняя часть извлекает эти данные, задний конец возвращает то, что он извлекает из своего собственного хранилища данных.
  2. Всякий раз, когда внешний интерфейс запрашивает данные, служба обратного вызова вызывает внешний API, обрабатывает важную информацию и возвращает ее на передний конец. Нет хранилища данных. Следующим шагом к этому является то, что может сделать это в задней части, противоположной простому вызову внешнего API в интерфейсе?

Существуют ли другие типы реализаций, которые я не учитывал?

ответ

2

Вы говорите о стандарте cache. Недостаток почти всегда связан с истечением срока действия кеша. Как долго полезны местные данные? Всегда ли это верно? Как вы обнаруживаете изменения? Вы пишете или записываете?

Если это не проблема, тогда у вас есть простой ответ, делайте много кеширования.

+0

Да, это можно увидеть как кеширование, я думаю. Это скорее обновление хранилища данных. Если вам нужно рассчитать числа, основанные на нескольких внешних данных API, вы не захотите вызывать их всех каждый раз, когда клиентский интерфейс запрашивает его. Иногда вы вычисляете это с помощью запланированной задачи, чтобы поддерживать актуальность данных. – user3808357