限制网络请求是谁的责任？
我正在开发一个从第三方网站检索信息的类库。如果在设定的时间段（~0.5 秒）内发出过多请求，则正在访问的网站将停止响应。
我的库的公共方法直接与 Web 服务器上的资源和文件相关。换句话说，每次调用方法时，都会创建一个 HttpWebRequest 并将其发送到服务器。如果一切顺利，一个 XML 文件将返回给调用者。但是，如果这是 0.5 秒内的第二个 Web 请求，则请求将超时。
我的困境在于我应该如何处理请求限制（如果有的话）。显然，我不希望调用者坐等响应——尤其是当我完全确定他们的请求会超时时。
对于我的库来说，对我创建的 Web 请求进行排队和限制是否更有意义，或者如果客户端在 API 调用之间没有等待足够长的时间，我的库应该简单地抛出异常吗？
I am working on a class library that retrieves information from a third-party web site. The web site being accessed will stop responding if too many requests are made within a set time period (~0.5 seconds).
The public methods of my library directly relate to a resource an file on the web server. In other words, each time a method is called, an HttpWebRequest is created and sent to the server. If all goes well, an XML file is returned to the caller. However, if this is the second web request in less than 0.5s, the request will timeout.
My dilemma lies in how I should handle request throttling (if at all). Obviously, I don't want the caller sit around waiting for a response -- especially if I'm completely certain that their request will timeout.
Would it make more sense for my library to queue and throttle the webrequests I create, or should my library simply throw an exception if the a client does not wait long enough between API calls?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
库的概念是让客户端代码尽可能少地担心。因此，我会将请求排队并及时返回结果作为图书馆的工作。在理想情况下，您将使用回调或委托模型，以便客户端代码可以异步操作，而不会阻塞 UI。您还可以提供跳过队列的选项（如果操作太快就会失败），甚至可能在队列模型中提供优先级。
我还认为图书馆作者有责任默认成为一个好公民，并且图书馆的默认操作有责任遵守数据提供者的条件。
The concept of a library is to give its client code as little to worry about as possible. Therefore I would make it the libraries job to queue requests and return results in a timely manner. In an ideal world you would use a callback or delegate model so that the client code can operate in asynchronously, not blocking the UI. You could also offer the option for skipping the queue, (and failing if it operates too soon) and possibly even offer priorities within the queue model.
I also believe it is the responsibility of the library author to default to being a good citizen, and for the library's default operation to be to comply to the conditions of the data provider.
我想说的是，您正在处理两个独立的系统，并且两个系统都应该采取措施来保护自己免受过度负载的影响。 Web 服务器应拒绝传入连接，并且客户端库应采取措施减少对缓慢或无响应的外部服务发出的请求。在客户端处理此问题的常见模式是“断路器”，它包装对外部服务的调用，并在失败后的一段时间内快速失败。
I'd say both - you're dealing with two independent systems and both should take measures to defend themselves from excessive load. The web server should refuse incoming connections, and the client library should take steps to reduce the requests it makes to a slow or unresponsive external service. A common pattern for dealing with this on the client is 'circuit breaker' which wraps calls to an external service, and fails fast for a certain period after failure.
在我看来，这是 Web 服务器的责任。因为关键负载取决于硬件、网络带宽等许多超出应用程序控制范围的因素，所以它不应该尝试处理它。 IIS 可以根据各种配置选项限制流量。
That's the Web server's responsibility, imo. Because the critical load depends on hardware, network bandwidth, etc a lot of things that are outside of your application's control, it should not concern itself with trying the deal with it. IIS can throttle traffic based on various configuration options.
是什么样的客户？这是一个交互式客户端，例如：基于 GUI 的应用程序？
在这种情况下，您可以将其等同于网络浏览器场景，并将超时显示给调用者。另外，如果您确定该网络服务器正在限制请求，您可以告诉客户端他必须等待给定的时间段才能重试。这样客户端就不会不断地重新发出请求，并且在第一次超时时就会知道发出太快的请求是没有用的。
What kind of client is it? Is this an interactive client, for eg: GUI based app?
In that case, you can equate that to a webbrowser scenario, and let the timeout surface to the caller. Also, if you know for sure that this webserver is throttling requests, you can tell the client that he has to wait for a given time period before retrying. In that way, the client will not keep on re-issuing requests, and will know when the first timeout occurs that it is futile to issue requests too fast.