网站是否也应该是Web资源？ [英] Should a Web site also be a Web resource?
问题描述
每个网络应用程序 - 每个网站 - 都是一项服务。 （...）使网站易于使用的网站功能也使网络服务API易于程序员使用。
Richardson和Ruby，RESTFul Web Services
按照我的意愿，一个网站是Web服务还提供其资源的多种表示，具体取决于用户代理请求的内容。可以这么说，API就是网站本身，不是单独提供的。
As I intend it, a Web site that is also a Web service provides multiple representations of its resources, depending on what the user-agent requests. The API, so-to-speak, is the Web site itself, and is not provided separately.
对于许多流行的REST API来说，情况并非如此。在野外。例如，Twitter的API位于 http://api.twitter.com/1/ ， URI中的'1'是API本身的版本。 Socialcast还在 https://demo.socialcast.com/api/ 上提供REST API，第三个级别名称是它所处理的网络的名称。
This isn't the case for many popular "REST APIs" out in the wild. Twitter's API, for example, is located at http://api.twitter.com/1/, the '1' in the URI being the version of the API itself. Socialcast also provides a REST API at https://demo.socialcast.com/api/ , the third level name being the name of the network it addresses.
这对我来说似乎不对。如果我的博客位于 http://www.example.com/blog ，我不需要在不同的位置提供API，仅为机器人提供JSON。而不是 http://www.example.com/blog/posts/ 和 http://api.example.com/blog/posts ，两个不同的URI，我应该只有前者和多个表示可用，其中 application / json 用于我希望提供给用户的JSON API。
This seems wrong to me. If I have my blog at http://www.example.com/blog, I shouldn't need to provide an API at a different location, serving JSON just for robots. Instead of having http://www.example.com/blog/posts/ and http://api.example.com/blog/posts, two different URIs, I should have just the former, and multiple representations available, among which application/json for the JSON API I wish to provide to my users.
示例1 ：浏览器询问我博客上的帖子;
Example 1: a browser asking for the posts on my blog;
请求：
curl -i \
-H "Accept: text/html" \
-X GET \
http://www.example.org/blog/posts/
回复：
200 OK
Content-Type: text/html; charset=utf-8
<html><body><h1>Posts</h1><ol><li><h2>My first post ...
示例2 ：相同的URI，但这次机器人发出请求;
Example 2: same URI, but this time a robot makes the request;
请求：
curl -i \
-H "Accept: application/json" \
-X GET \
http://www.example.org/blog/posts/
回复：
200 OK
Content-Type: text/html; charset=utf-8
{
"posts": [
{
"id": 1,
"title": "My first post" ...
API的版本号应编码在请求标题的Accept字段中，最重要的是避免强力输入类似Twitter的URI（statuses / show.json？id = 210462857140252672或statuses / show / 210462857140252672.json）。
Version numbers for APIs should be encoded in the "Accept" field of the request headers, and above all avoiding strongly typing the URIs like Twitter does ("statuses/show.json?id=210462857140252672" or "statuses/show/210462857140252672.json").
我可以通过统一的方法失去一些灵活性（但是，不应该酷URI永远不会改变？），但我认为坚持REST（或至少我对它的解释）会带来更多好处。
I could lose some flexibility by going for the unified approach (but, shouldn't Cool URIs never change?), but I think adhering to REST (or at least my interpretation of it) would provide more benefit.
哪个是更正确的方法：分离API和网站，或统一它们？
Which is the more correct approach: separating the API and the Web site, or unifying them?
推荐答案
这里没有对错。当您的API开发受特定客户端要求驱动时，REST和RFC过于紧密可能会很困难。
There is no right or wrong here. Following REST and RFCs too closely may prove to be difficult when your API development is driven by specific client requirements.
实际上，与API客户端相比，人类用户具有不同的行为模式，因此需要不同的处理方式。最生动的区别在于，许多API都是数据密集型，专为批处理操作和数据转储而设计，而人类用户的应用程序则更具反应性，并且通常按要求逐步执行操作。因此，在许多项目中，API URL设计优化，以避免在多个网络往返和重复存储调用上浪费客户端和服务器资源。
In reality, human users have different behaviour patterns compared to API clients, and therefore require different treatment. The most vivid distinction comes from the fact that many APIs are very data intensive, designed for batch operations and data dumping, whereas applications for human users are more "reactive" and often do things step-by-step, request-by-request. As a consequence, in many projects APIs URL design is optimised to avoid wasting client and server resources on multiple network roundtrips and repeat storage calls.
在幕后，API实现通常与核心应用程序有不同的设计，针对API提供的操作进行了优化。例如，API实现可以使用单独的缓存策略。现在，如果您拆分代码，则可能需要创建仅处理API调用的主机群集。这就是将API放在另一个域上变得有利于负载管理：单独的域允许在高负载站点上实现更简单的负载平衡。相比之下，当您在同一域名上使用/ api URL前缀（但具有单独的集群）时，您需要一个智能（L7感知）负载均衡器来完成在API和Web前端集群之间拆分请求流的工作，但是这样的负载平衡器更贵。
Under the hood, API implementations often have different design from core application, optimised for the kind of operations APIs provide. For example, API implementation may use a separate caching strategy. Now if you split the code out, you may want to create a cluster of hosts that only handle the API calls. That is where placing API on another domain becomes beneficial for load management: a separate domain allows for simpler load balancing on high-load sites. In comparison, when you use /api URL prefix on the same domain name (but have separate clusters) then you need a smart (L7-aware) load balancer to do the job of splitting the request flow between API and web front end clusters, but such load balancers are more expensive.
因此，可能有非常好的技术原因可能会让Twitter之类的人将API分开，但对其他实现的引用可能不适用于你的项目。如果您处于设计的早期阶段，您可能希望从同一域上的统一URL方案开始，但最终您可能会发现有很好的现实用例可以让您更改方法，然后......重构。
So there may be very good technical reasons why the likes of Twitter separate out the API, but references to other implementations may not apply to YOUR project. If you are at early stages of design, you may want to start with a unified URL scheme on the same domain, but eventually you may find that there are good real-life use cases that make you change the approach, and then ... refactoring.
P.S。这里有关于版本控制的冗长讨论 - API版本控制的最佳实践？
P.S. there is a lengthy discussion on versioning here - Best practices for API versioning?
PSS我发现强类型的URL有助于快速调试。您可以使用.json将URL放入浏览器中，并快速获取结果而无需切换到命令行。但同意你的说法，接受标题是首选方法
P.S.S. I find strongly typed URLs helpful in quick debugging. You can simply put a URL into the browser with .json and quickly get the result without switching to the command line. But agree with you that "accept" header is the preferred method
P.S.S.S。 API的SEO？我可以看到一个好的URL设计如何有益，但对于搜索引擎，如果您的服务在相同的路径/域名上提供多种输出格式，它可能无关紧要。在一天结束时，搜索引擎是为人类用户构建的，而人类用户不使用XML和JSON。
P.S.S.S. SEO for APIs? I can see how a good URL design can be beneficial, but for a search engine its probably irrelevant if your service provides multiple output formats on the same path / domain name. In the end of the day, search engines are built for human users, and human users don't consume XML and JSON.
这篇关于网站是否也应该是Web资源？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
