RESTful API和同一URL中的网站
例如，查看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和相同的服务器端处理机制如何？ 如何将整个渲染任务转移到客户端（浏览器）并使服务器仅处理数据？
金善焕（2008）
XSLT是可以帮助我们做到这一点的技术。 在“浏览器中的XML + XSLT”中，我简要地解释了它在浏览器中的工作方式。 简而言之，服务器返回带有一些数据的XML和指向XSL样式表的链接。 在浏览器中执行的样式表将XML转换为HTML。 XSL语言与其他任何渲染引擎（如JSP，JSF，Tiles或您拥有的东西）一样强大。 实际上，它功能更强大。
使用这种方法，我们从服务器上删除了整个渲染层（MVC范例中的“视图”），并将其移至浏览器。
如果我们能够做到，则Web服务器将仅使用RESTful API，并且每个响应页面都将附加XSL样式表。 我们得到什么？ 我们将在文章结尾处稍后讨论。 现在，让我们看看我们将面临哪些问题：
- JSON没有呈现层。 没有用于JSON的XSLT。 因此，我们将不得不忘记JSON，而只保留XML。 对我来说，这听起来很不错。 其他人则不喜欢XML，而只喜欢使用JSON。 从来没有了解他们:)
- 并非所有浏览器都支持XSLT 2.0。 XSLT 1.0甚至仅受其中一些支持。 例如，Internet Explorer 8根本不支持XSLT。
- 浏览器仅支持
GET和POSTHTTP方法，而传统的RESTful API至少也利用PUT和DELETE。
第一个问题不是真正的问题。 这只是品味（和教育水平）的问题。 最后两个问题更为严重。 让我们讨论一下。
服务器上的XSL转换
某些浏览器不支持XSLT。 我们该如何解决？
我认为最好的方法是解析每个请求中的User-Agent HTTP标头，然后进行猜测，不管这个特定版本的浏览器是否支持XSLT。 这样做并不难，因为此兼容性信息是公开的。
如果浏览器不支持XSLT，我们可以在服务器端进行转换。 我们已经有了服务器生成的带有数据的XML，并且已经附加了XSL。 我们要做的就是将后者应用于前者并获得HTML页面。 然后，我们将HTML返回到浏览器。
除此之外，我们还可以注意Accept标头。 如果将其设置为application/xml或text/xml ，那么无论User-Agent在说什么，我们都会返回XML。 基本上，这意味着某些API客户端正在与我们对话，而不是与浏览器对话。 这个客户对HTML并不感兴趣，而对XML格式的纯数据感兴趣。
POST代替PUT
没有解决方法。 浏览器对PUT或DELETE一无所知。 因此，我们还应该在我们的RESTful API中忘记它们。 我们应该仅使用两种方法设计API： GET和POST 。 这有可能吗？ 是。 为什么不？ 它看起来并不像所有六个方法一样花哨（某些API也使用OPTIONS和HEAD ），但是它可以工作。
我们获得什么？
好，这是一个问题-我们为什么需要这个？ 大多数人现在的工作方式有什么问题？ 为什么我们不能将网站与API分开？ 如果将它们结合起来，将会获得什么好处？
自2011年以来，我一直将它们组合到我使用过的所有Web应用程序中。我最大的好处是避免了代码重复。
显然，在服务器中我们不复制控制器（对于MVC）。 我们只有一层控制器，它们同时控制API和网站（因为它们现在是一回事）。
避免代码重复是非常重要的成就。 而且，我相信它是任何软件项目的最重要目标。
这些小型Web应用程序的工作原理与上面所述完全相同： s3auth.com ， stateful.co和bibrarian.com 。 它们都是开源的，您可以在Github中查看其源代码。
相关文章
您可能还会发现以下有趣的帖子：
翻译自: https://www.javacodegeeks.com/2014/09/restful-api-and-a-web-site-in-the-same-url.html