The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
以GitHub RESTful API为例。要获取有关存储库的信息，您应该向api.github.com/repos/yegor256/rultor 发送GET请求。作为响应，您将获得一个JSON文档，其中包含有关yegor256/rultor存储库的所有详细信息。试试看，这个URL不需要任何身份验证。
要在漂亮的HTML+CSS页面中打开相同的存储库，您应该使用不同的URL：github.com/yegor256/rultor。URL不同，服务器端肯定不同，但数据的性质完全相同。唯一改变的是表示层。
在第一种情况下，我们得到的是JSON；在第二种情况下，我们得到的是HTML。
如何将它们结合起来？如何使用相同的URL和相同的服务器端处理机制来处理它们？如何将整个渲染任务转移到客户端（浏览器）并让服务器仅处理数据？
XSLT是可以帮助我们做到这一点的技术。在《在浏览器中使用XML+XSLT》中，我简要解释了它在浏览器中的工作原理。简而言之，服务器返回一个带有一些数据和指向XSL样式表的链接的XML。在浏览器中执行的样式表将XML转换为HTML。XSL语言和其他渲染引擎（如JSP、JSF、Tiles等）一样强大。实际上，它更加强大。
使用这种方法，我们从服务器中完全移除了整个渲染层（MVC范式中的“视图”），并将其移动到了浏览器中。
如果我们能够实现这一点，Web服务器将仅公开一个RESTful API，并且每个响应页面都将附带一个XSL样式表。我们能得到什么？我们将在本文末尾进行讨论。现在，让我们看看我们将面临哪些问题：
XSLT 2.0 不被所有浏览器支持。甚至 XSLT 1.0 也只被其中一些浏览器支持。例如，Internet Explorer 8 根本不支持 XSLT。
浏览器仅支持
GET和POSTHTTP 方法，而传统的 RESTful API 还会利用至少PUT和DELETE。
第一个问题并不是真正的问题。这只是一个品味问题（以及教育水平问题）。最后两个问题更为严重。让我们来讨论一下它们。
XSLT在一些浏览器中不受支持。我们该如何解决这个问题？
我觉得最好的方法是在每个请求中解析User-AgentHTTP头，并猜测这个浏览器的特定版本是否支持XSLT。这并不难做到，因为这些兼容性信息是公开的。
如果浏览器不支持XSLT，我们可以在服务器端进行转换。我们已经有了由服务器生成的带有数据的XML，也已经有了附加在其上的XSL。我们只需要将后者应用于前者，得到一个HTML页面，然后将HTML返回给浏览器。
除此之外，我们还可以关注Accept头。如果它被设置为application/xml或text/xml，无论User-Agent说什么，我们都返回XML。这基本上意味着某个API客户端正在与我们交互，而不是一个浏览器。而这个客户端对HTML不感兴趣，而是对纯数据的XML格式感兴趣。
这是没有变通办法的。浏览器对于PUT或DELETE一无所知。所以，在我们的RESTful API中，我们也应该忘记它们。我们应该仅使用两种方法设计我们的API：GET和POST。这是可能的吗？是的。为什么不呢？虽然不像使用六种方法那样花哨（一些API还使用OPTIONS和HEAD），但它仍然可以运行。
好的，这里是问题——为什么我们需要这个呢？目前大多数人的工作方式有什么问题吗？为什么我们不能将网站与API分离？如果我们将它们合并，我们能得到哪些好处呢？
自2011年以来，我一直在所有的Web应用程序中将它们合并在一起。我目前经历到的最大优势是避免代码重复。
很明显，在服务器上我们不会重复复制控制器（在MVC的情况下）。我们有一个控制器层，它们同时控制着API和网站（因为它们现在是一体的）。
避免代码重复是一个非常重要的成果。此外，我认为这是任何软件项目的最重要目标。
这些小的Web应用程序正如上面所解释的那样工作：s3auth.com, stateful.co, bibrarian.com。它们都是开源的，你可以在GitHub上查看它们的源代码。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 15:59
