Чья это ответственность за ограничение веб-запросов?

Question

Я работаю над библиотекой классов, которая получает информацию со стороннего веб-сайта. Доступ к веб-сайту перестанет отвечать, если в течение установленного периода времени (~ 0,5 секунды) будет выполнено слишком много запросов.

Публичные методы моей библиотеки напрямую относятся к ресурсу файл на веб-сервере. Другими словами, каждый раз, когда вызывается метод, HttpWebRequest создается и отправляется на сервер. Если все идет хорошо, файл XML возвращается вызывающей стороне. Однако, если это второй веб-запрос менее чем за 0,5 с, запрос будет тайм-аут.

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

Было бы логичнее, чтобы моя библиотека ставила в очередь и ограничивала создаваемые мной веб-запросы, или же моя библиотека просто выдает исключение, если клиент не ждет достаточно долго между вызовами API?

Answer 1

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

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

Answer 2

Я бы сказал, что оба - вы имеете дело с двумя независимыми системами, и обе должны принять меры, чтобы защитить себя от чрезмерной нагрузки. Веб-сервер должен отклонять входящие соединения, а клиентская библиотека должна предпринимать шаги, чтобы уменьшить количество обращений к медленной или не отвечающей внешней службе. Распространенным шаблоном для решения этой проблемы на клиенте является «прерыватель цепи», который переводит вызовы во внешнюю службу и быстро завершает работу в течение определенного периода после сбоя.

Answer 3

Это ответственность веб-сервера, imo. Поскольку критическая нагрузка зависит от аппаратного обеспечения, пропускной способности сети и т. Д., А также от многих вещей, которые находятся вне контроля вашего приложения, не стоит пытаться разобраться с этим. IIS может регулировать трафик на основе различных параметров конфигурации.

Answer 4

Что это за клиент? Это интерактивный клиент, например, для приложения с графическим интерфейсом?

В этом случае вы можете приравнять это к сценарию веб-браузера и позволить тайм-ауту всплыть перед вызывающей стороной. Кроме того, если вы точно знаете, что этот веб-сервер регулирует запросы, вы можете сообщить клиенту, что ему нужно подождать определенный период времени, прежде чем повторять попытки. Таким образом, клиент не будет продолжать повторную выдачу запросов и будет знать, когда произойдет первый тайм-аут, что бесполезно слишком быстро выдавать запросы.