API开发，一个网关页面？
我目前正在开发一个 API，我决定的一件事是拥有一个 gateway.cfm 页面，客户端将请求发送到该页面，并使用 sig 进行验证等，网关处理该请求并通过调用组件将结果发回需要。
例如 gateway.cfm?component=getBooks&sig=232345343 将调用 getbooks 组件并返回 JSON。
忽略任何安全问题，由于所有请求都发送到一页，此 API 的性能是否会受到影响？或者，无论所有请求是否都发送到同一页面，这对 Web 服务器来说并不重要。
此外，这也将受到 SSL 的保护。
Im currently developing an API, and one thing that I decided was to have one gateway.cfm page that the client sends the request to with a sig for verification and etc, and the gateway processes the request and sends the result back by invoking the components needed.
For example gateway.cfm?component=getBooks&sig=232345343 will call the getbooks component and return the JSON.
Ignoring any security issues, will this api suffer and performance since all the requests are going to one page? Or does this not matter to the web server whether all the requests go to the same page or not.
Also this will be secured by SSL too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于服务器来说，所有请求都转到一页或不同的页面并不重要。至少，对于常见的网络服务器（例如 Apache/IIS）来说不是。
网络服务器有一个线程池，每个请求都会分配一个线程，每个线程执行其工作并完成。
不过，有一个细节。在较低级别上，处理请求的线程都读取相同的二进制/文本（不知道 cfm 是否被编译/解释），因此在很短的时间内该文件可能被锁定以供读取。如果请求数量巨大，这可能会带来惩罚。您只能通过基准测试和测试来确定这是否确实是性能瓶颈。
但我认为进行 SSL 握手会像读锁一样更快地降低性能。
It does not matter for the server if all requests go to one page or to different pages. At least, not for the common webservers (e.g. Apache/IIS).
A webserver has a threadpool, each request gets a thread assigned, each thread performs its work and finishes.
However, there is one detail. On a lower level, the threads that process the request all read the same binary/text (dont know if cfm is compiled/interpreted) so for a very short period of time the file is possibly locked for reading. That may introduce a penalty if the number of requests are enormous. You can only find out if this is really a performance bottleneck by benchmarking and testing.
But i think that doing the SSL handshake will kill performance much sooner as the reading lock.