If a client isn't already aware of the code, it decides what to do based on the first number:
- 1xx - continue receiving content
- 2xx - finished receiving content
- 3xx - follow redirect
- 4xx - client error occurred, show error page
- 5xx - server error occurred, show error page
So there is no harm in using better (but less commonly known) codes
- 2xx - You Don't Need Refresh
- 3xx - We're dealing with Refresh for you
- 4xx - Don't Bother Refreshing
- 5xx - Refresh, You Might Get Lucky
It's a universal namespace, just like UUIDs, but with just enough extra sauce to make it theoretically possible to do interesting things with it. So 'urn:isbn:0451450523' might represent The Last Unicorn, and if you fed it to your Kindle it might enable you to buy it, and if you fed it into Nook ditto, and if you fed it into Project Gutenberg you might get a notice that it won't fall out of copyright until A.D. 3172, and if you fed it into your browser it might do any of those things or just look it up on ibiblio or Wikipedia.
Unfortunately, like many good ideas, it didn't take off because folks couldn't imagine a profitable use for it.
<!-- AWS Elastic Beanstalk application version --> arn:aws:elasticbeanstalk:us-east-1:123456789012:environment/My App/MyEnvironment
<!-- IAM user name --> arn:aws:iam::123456789012:user/David
<!-- Amazon RDS tag --> arn:aws:rds:eu-west-1:001234567890:db:mysql-db
<!-- Amazon S3 bucket (and all objects in it)--> arn:aws:s3:::my_corporate_bucket/*
http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-na...
I don't know why they didn't use URNs. Probably because nobody else does.
Actually there aren't. There are like 60. It really shouldn't take too long to read over them: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
The idea of a globally unique, permanent identifier that would resolve to a URL to indicate the current location of a resource is fairly commonplace, isn't it? We've tried to bolt all sorts of equivalents onto the existing URL infrastructure without them.
I actually prefer the Wikipedia page[1] exactly because it includes more than just the canonical subset. For example, 451 is not yet official, but pretty much as close as you can get to a standard without having an actual standard (well, there's a draft).
[0]: http://www.iana.org/assignments/http-status-codes/http-statu... [1]: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Yes: I've interviewed some. Very few realise there's any more than GET/PUT/POST/DELETE, which astonished me: surely everyone's left an HTTP debugger running while updating an SVN repo or browsing a WebDAV share?
URN's I had not heard of, but the article didn't make it clear to me what problem they would solve.
Of course I know about HTTP verbs PUT and DELETE and HEAD-- is there really any web dev who doesn't? And I am pretty rigorous about using the appropriate one (unlike with status codes).
I don't have an opinion on how apps are isolated from the web and don't have interlinks between them. Don't really use mobile apps myself except utility ones like Spotify and Netflix.