4 ms·
All of your examples still portray uniformity: > git://github.com/thoughtbot/paperclip.git You are accessing a resource that is partially identified by the us
by m0th87 17y ago
All of your examples still portray uniformity:
> git://github.com/thoughtbot/paperclip.git
You are accessing a resource that is partially identified by the username.
> smtp://user:pass@hostname/domain
The username and password is used for authentication to access the resource, but is part of its unique identification.
> http://news.ycombinator.com/user?id=krainboltgreene http://news.ycombinator.com/user?id=krainboltgreene
The mistake actually lies with HN, because part of what should be used to identify the resource is instead a param.
> chrome://history/
This still fits because you are accessing a uniquely identified resource. Just because it is user-dependent does not mean it breaks REST.
- blasdel 17y agoURL Parameters ≠ RPC The resource is the whole string between the domain and the fragment identifier. '/' is no different from '?' or '&' — it's all the same once you drop your false-REST preconceptions. The HTML spec does define a standard for concatenating the name-value pairs from form elements onto target attributes for use in GET requests, but that doesn't reify it into the definition of HTTP, much less the definition of REST.
- m0th87 17y agoExcept the use of parameters for resource identification both breaks REST and isn't SEO-friendly. Forms somewhat break this for GET submissions, but do at least adhere for POST.