Twitter REST API中ID位置的一致性问题

Question

有人能用REST术语解释一下Twitter在这两个调用中参数放置的设计决策吗？看起来:id的放置是不一致和武断的（尽管显然这是有意为之）。

GET statuses/:id/retweeted_by
Show user objects of up to 100 members who retweeted the status.

GET statuses/retweets/:id
Returns up to 100 of the first retweets of a given tweet.

他们的API（https://dev.twitter.com/docs/api）中还有其他类似的例子，所以我肯定漏掉了什么。

谢谢！

- Charles Offenbacher

Answer 1

这只是我的猜测

Twitter上的某人曾指出，Twitter API在几个servlet上运行。我只能假设这与映射/retweets/*比映射每个单独组合更容易相关。

更新：我认为API本身的历史也可能是相关的。Twitter的API在过去几年中并没有真正改变太多，如果它确实发生了变化，那么就是因为新增了新功能。诸如GET statuses/show/:id这样的终端是旧的，而GET statuses/retweets/:id则较新。如果Twitter在某个时候决定更改命名约定，他们不能仅仅重命名旧的，因为这会破坏应用程序。

我另一个理论是，GET statuses/retweets/:id实际上不是关于Tweet :id本身的，而是关于基于它的推文。通过返回用户而不是其他状态，GET statuses/:id/retweeted_by与推文本身直接相关。

我也经常被命名一致性所困惑。虽然我确定他们有他们的理由。

- Tom van der Woerdt

---

因为不同的API实现在不同的Servlet中，所以一致性受到影响了？左手不知道右手在干什么？ - dthorpe

嗯，是的，说得有道理，那听起来不太可能。我已经更新了我的帖子，加入了一些其他的理论 :-) - Tom van der Woerdt

Answer 2

我最终向Twitter的一位朋友进行了核实，他说：

“我刚刚与最初编写这两个API端点的人交谈，他不记得为什么这样设计。不过，回答你的问题，可能没有一个很好的RESTful原因来支持这种设计。”

- Charles Offenbacher