Look closely at URI's for ordinary web resources. Those are your template. Think of directory trees; use simple Linux-like file and directory names.
HelloWorld isn't a really good class of resources. It doesn't appear to be a "thing". It might be, but it isn't very noun-like. A greeting is a thing.
user-id might be a noun that you're fetching. It's doubtful, however, that the result of your request is only a user_id. It's much more likely that the result of the request is a User. Therefore, user is the noun you're fetching
www.example.com/greeting/user/x/
Makes sense to me. Focus on making your REST request a kind of noun phrase -- a path through a hierarchy (or taxonomy, or directory). Use the simplest nouns possible, avoiding noun phrases if possible.
Generally, compound noun phrases usually mean another step in your hierarchy. So you don't have /hello-world/user/ and /hello-universe/user/. You have /hello/world/user/ and hello/universe/user/. Or possibly /world/hello/user/ and /universe/hello/user/.
The point is to provide a navigation path among resources.
[POST or Create](To the *collection*)
sub.domain.tld/class_name.{media_type}
[GET or Read](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}
[PUT or Update](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}
[DELETE](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}
[GET or Search](of a *collection*, FRIENDLY URL)
sub.domain.tld/class_name.{media_type}/{var}/{value}/{more-var-value-pairs}
[GET or Search](of a *collection*, Normal URL)
sub.domain.tld/class_name.{media_type}?var=value&more-var-value-pairs
'UserId' is wholly the wrong approach. The Verb (HTTP Methods) and Noun approach is what Roy Fielding meant for The REST architecture. The Nouns are either:
A Collection of things
A thing
One good naming convention is:
[POST or Create](To the *collection*)
sub.domain.tld/class_name.{media_type}
[GET or Read](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}
[PUT or Update](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}
[DELETE](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}
[GET or Search](of a *collection*, FRIENDLY URL)
sub.domain.tld/class_name.{media_type}/{var}/{value}/{more-var-value-pairs}
[GET or Search](of a *collection*, Normal URL)
sub.domain.tld/class_name.{media_type}?var=value&more-var-value-pairs
Where {media_type} is one of: json, xml, rss, pdf, png, even html.
It is possible to distinguish the collection by adding an 's' at the end, like:
'users.json' *collection of things*
'user/id_value.json' *single thing*
But this means you have to keep track of where you have put the 's' and where you haven't. Plus half the planet (Asians for starters) speaks languages without explicit plurals so the URL is less friendly to them.
No. REST has nothing to do with URI naming conventions. If you include these conventions as part of your API, out-of-band, instead of only via hypertext, then your API is not RESTful.
If you authenticate your clients with Oauth2 I think you will need underscore for at least two of your parameter names:
client_id
client_secret
I have used camelCase in my (not yet published) REST API. While writing the API documentation I have been thinking of changing everything to snake_case so I don't have to explain why the Oauth params are snake_case while other params are not.
I would say that it's preferable to use as few special characters as possible in REST URLs. One of the benefits of REST is that it makes the "interface" for a service easy to read. Camel case or Pascal case is probably good for the resource names (Users or users). I don't think there are really any hard standards around REST.
Also, I think Gandalf is right, it's usually cleaner in REST to not use query string parameters, but instead create paths that define which resources you want to deal with.
发布评论
评论（10）
我认为你应该避免戴骆驼帽。 标准是使用小写字母。 我还会避免使用下划线并使用破折号，
因此您的 URL 应该如下所示（忽略您要求的设计问题:-)）
I think you should avoid camel caps. The norm is to use lower case letters. I would also avoid underscores and use dashes instead
So your URL should look like this (ignoring the design issues as you requested :-))
Dropbox 的 REST API，Twitter、Google Web Services 和 Facebook 都使用下划线。
The REST API for Dropbox, Twitter, Google Web Services and Facebook all uses underscores.
仔细查看普通 Web 资源的 URI。 这些是你的模板。 想想目录树； 使用简单的类似 Linux 的文件和目录名称。
HelloWorld并不是一个真正好的资源类。 它似乎不是一个“东西”。 可能是，但它不太像名词。问候是一件事。user-id可能是您要获取的名词。 然而，令人怀疑的是，您的请求结果只是一个 user_id 。 请求的结果更有可能是用户。 因此，user是您要获取的名词对我来说有意义。 专注于使您的 REST 请求成为一种名词短语——通过层次结构（或分类法或目录）的路径。 尽可能使用最简单的名词，尽可能避免使用名词短语。
一般来说，复合名词短语通常意味着层次结构中的另一个步骤。 所以你没有
/hello-world/user/和/hello-universe/user/。 您有/hello/world/user/和hello/universe/user/。 或者可能是/world/hello/user/和/universe/hello/user/。重点是提供资源之间的导航路径。
Look closely at URI's for ordinary web resources. Those are your template. Think of directory trees; use simple Linux-like file and directory names.
HelloWorldisn't a really good class of resources. It doesn't appear to be a "thing". It might be, but it isn't very noun-like. Agreetingis a thing.user-idmight be a noun that you're fetching. It's doubtful, however, that the result of your request is only a user_id. It's much more likely that the result of the request is a User. Therefore,useris the noun you're fetchingMakes sense to me. Focus on making your REST request a kind of noun phrase -- a path through a hierarchy (or taxonomy, or directory). Use the simplest nouns possible, avoiding noun phrases if possible.
Generally, compound noun phrases usually mean another step in your hierarchy. So you don't have
/hello-world/user/and/hello-universe/user/. You have/hello/world/user/andhello/universe/user/. Or possibly/world/hello/user/and/universe/hello/user/.The point is to provide a navigation path among resources.
“UserId”是完全错误的方法。 动词（HTTP 方法）和名词方法是 Roy Fielding 的意思 REST 架构。 名词可以是：
一个好的命名约定是：
其中 {media_type} 是以下之一：json、xml、rss、pdf、png，甚至html。
可以通过在末尾添加“s”来区分集合，例如：
但这意味着您必须跟踪已放置“s”的位置和未放置“s”的位置。 再加上半个地球（首先是亚洲人）
使用没有明确复数的语言，因此 URL 对他们不太友好。
'UserId' is wholly the wrong approach. The Verb (HTTP Methods) and Noun approach is what Roy Fielding meant for The REST architecture. The Nouns are either:
One good naming convention is:
Where {media_type} is one of: json, xml, rss, pdf, png, even html.
It is possible to distinguish the collection by adding an 's' at the end, like:
But this means you have to keep track of where you have put the 's' and where you haven't. Plus half the planet (Asians for starters)
speaks languages without explicit plurals so the URL is less friendly to them.
不。REST 与 URI 命名约定无关。 如果您将这些约定作为带外 API 的一部分而不是仅通过超文本包含，那么您的 API 就不是 RESTful。
有关详细信息，请参阅 http://roy.gbiv。 com/untangled/2008/rest-apis-must-be-hypertext-driven
No. REST has nothing to do with URI naming conventions. If you include these conventions as part of your API, out-of-band, instead of only via hypertext, then your API is not RESTful.
For more information, see http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
域名不区分大小写，但 URI 的其余部分当然可以。 假设 URI 不区分大小写是一个很大的错误。
Domain names are not case sensitive but the rest of the URI certainly can be. It's a big mistake to assume URIs are not case sensitive.
我在 http://我们在产品中使用过的soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html。 指导方针总是有争议的……我认为一致性有时比让事情变得完美更重要（如果有这样的事情的话）。
I have a list of guidelines at http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html which we have used in prod. Guidelines are always debatable... I think consistency is sometimes more important than getting things perfect (if there is such a thing).
如果您使用 Oauth2 验证您的客户端，我认为您至少需要两个参数名称使用下划线：
我在我的（尚未发布）REST API 中使用了驼峰命名法。 在编写API文档时，我一直在考虑将所有内容更改为snake_case，这样我就不必解释为什么Oauth参数是snake_case而其他参数不是。
请参阅：https://www.rfc-editor.org/rfc/rfc6749
If you authenticate your clients with Oauth2 I think you will need underscore for at least two of your parameter names:
I have used camelCase in my (not yet published) REST API. While writing the API documentation I have been thinking of changing everything to snake_case so I don't have to explain why the Oauth params are snake_case while other params are not.
See: https://www.rfc-editor.org/rfc/rfc6749
我不认为驼峰式大小写是该示例中的问题，但我想上述示例的更 RESTful 命名约定将是：
api.service.com/helloWorld/userId/x
而不是将 userId 设为查询参数（其中是完全合法的）我的例子表示该资源在我看来是一种更 RESTful 的方式。
I don't think the camel case is the issue in that example, but I imagine a more RESTful naming convention for the above example would be:
api.service.com/helloWorld/userId/x
rather then making userId a query parameter (which is perfectly legal) my example denotes that resource in, IMO, a more RESTful way.
我想说的是，最好在 REST URL 中使用尽可能少的特殊字符。 REST 的好处之一是它使服务的“界面”易于阅读。 骆驼大小写或帕斯卡大小写可能适合资源名称（用户或用户）。 我认为 REST 确实没有任何硬性标准。
另外，我认为甘道夫是对的，在 REST 中，不使用查询字符串参数通常更干净，而是创建定义要处理哪些资源的路径。
http://api.example.com/HelloWorld/Users/12345/订单/3/等
I would say that it's preferable to use as few special characters as possible in REST URLs. One of the benefits of REST is that it makes the "interface" for a service easy to read. Camel case or Pascal case is probably good for the resource names (Users or users). I don't think there are really any hard standards around REST.
Also, I think Gandalf is right, it's usually cleaner in REST to not use query string parameters, but instead create paths that define which resources you want to deal with.
http://api.example.com/HelloWorld/Users/12345/Order/3/etc