TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

General principles for good URI design for RESTful and HTTP applications

97 点作者 ibrahimcesar超过 13 年前

7 条评论

arethuza超过 13 年前
"(Note: I did not say "RESTful URI design"; URIs are essentially opaque in REST.)"<p>Glad to see that - I'm seriously puzzled by the number of references I see to "RESTful URIs".
评论 #3548216 未加载
评论 #3548079 未加载
moozeek超过 13 年前
All this is nice and well, but how would one build an "unsubscribe" link into a newsletter system without a GET request changing the state of the resource (i.e. deleting the email address from the active recipients table by just clicking a link)?<p>Would this be the exception to the rule or is this problem totally unrelated to REST?<p>BTW: I'm not debating, I really wanna know.
评论 #3548418 未加载
评论 #3548698 未加载
评论 #3548668 未加载
romaniv超过 13 年前
<i>"Don't use query parameters to alter state" "Don't fall into RPC with your URIs"</i><p>I can see the benefit of doing some of the things on the list, but I never understood what's the motivation behind these two suggestions. What are the practical benefits? (Specifically, what are the benefits for a <i>web application</i>, rather than a web app?)<p>I can give you some <i>considerable</i> benefits of doing the opposite. My favorite URL scheme looks like this: "<a href="http://example.com/?Class.method.id.parts&#38;param=x" rel="nofollow">http://example.com/?Class.method.id.parts&#38;param=x</a>.<p>It enables automatic routing without the need to write explicit, case-by-case routing logic or .htaccess files. It doesn't mess up the base path, so I don't need to do some magic when writing URLs. Moreover, it's <i>straightforward</i>. It's easy to see what's going on on the web pages, in the code and in the logs, because knowing a URL means immediately knowing which controller and action are involved (which is not the case with clever resource-mapping schemes).
评论 #3548027 未加载
评论 #3548865 未加载
rkalla超过 13 年前
In this same vein, I am curious what you guys think of using semi-colon and comma characters in URLs when pointing at an endpoint that generates a response that would typically be provided by a query string, e.g.:<p><pre><code> http://site.com/generate;lang=en,size=32,weight=78 </code></pre> RESTful Web Services Cookbook[1] gave me the idea (a fantastic book) and what I like about it, is that interstitial proxy software seems to molest the URL less where as some refuse to pass through query string params for some reason (e.g. CloudFront).<p>Anyone see any glaring issues with this?<p>[1] <a href="http://www.amazon.com/RESTful-Web-Services-Cookbook-Scalability/dp/0596801688/ref=sr_1_1?ie=UTF8&#38;qid=1328307149&#38;sr=8-1" rel="nofollow">http://www.amazon.com/RESTful-Web-Services-Cookbook-Scalabil...</a>
decklin超过 13 年前
My first thought was "maybe we should back up and emphasize that resources are nouns before going further", but if you scroll up you'll see that this was actually the original question asked (how do I avoid naming them with verbs?).
评论 #3548042 未加载
pooriaazimi超过 13 年前
This article on how to design a RESTful API is really great: <a href="http://www.ibm.com/developerworks/webservices/library/ws-restful/" rel="nofollow">http://www.ibm.com/developerworks/webservices/library/ws-res...</a>
peterwwillis超过 13 年前
Holy shit, why hasn't this been around forever?<p>I forgot about 2?? responses other than 200, going to implement that now. Also going to implement 418 just because it's fun.