为了快速构建搜索网站，我计划在两个团队之间分配工作：一个用于构建搜索引擎，另一个用于构建Web UI（移动/桌面）。我的计划是将搜索引擎构建为一组基于.NET 3.5的REST服务。 UI可以使用其他一些技术构建。
问题：REST接口可能是性能瓶颈吗？如何最好地避免这种情况？
答案 0 :(得分：1)
在这种情况下，REST不可能成为瓶颈。从您的帖子中不清楚您是直接从客户端的HTML UI进行REST调用，还是在后端进行服务器到服务器的REST调用。所以我将在下面介绍两种情况。
如果您的客户端用户界面和服务器之间正在进行REST调用，那么使用REST或其他HTTP远程处理方法相对较少 - 在后端执行搜索所需的时间然后将结果发回客户端应该使REST调用本身的影响相形见绌。如果您想提高性能，请关注客户端网络技巧（例如HTTP压缩，正确的缓存标头等）并优化您的搜索引擎本身。
如果您的架构是一层服务器（托管您的Web UI）调用另一层（您的搜索引擎），那么通过REST在这些层之间进行调用也不应该增加太多的总体延迟。这是因为（与上面相同）运行搜索并将结果发送回客户端通常至少需要几百毫秒，而后端REST调用的开销（如果正确完成）通常为50毫秒或更少。
也就是说，很容易弄乱服务器到服务器HTTP调用的客户端。例如，许多HTTP客户端库（包括.NET）将默认限制并发客户端连接的数量，这对于构建实际的客户端应用程序是有意义的，但如果从实际上是“客户端”使用它将会破坏您的可伸缩性服务器同时为数百个用户服务。其他潜在的问题包括身份验证问题，代理问题，DNS等。因此，请谨慎构建和配置您的REST客户端代码，并确保使用几百个并发用户进行负载测试！
答案 1 :(得分：0)
没有。 REST不是（通常也不是）瓶颈。 REST 是 HTTP而没有花哨的HTML页面。它比普通网页更便宜，更快捷。
答案 2 :(得分：-1)
我认为它不应该影响你的性能，但要正确使用REST服务.Net有ASP.Net MVC，它完全支持REST。
请务必仔细阅读此链接http://www.ytechie.com/2008/10/aspnet-mvc-what-about-seo.html