Comments (20)
any thoughts on this? seems like having a standardized way to link to "home documents" (whatever media type they may use) could be a useful thing to add. if you agree, i can add a section.
from i-d.
if "home" is added, it might be interesting to see how it compares to the relation types proposed by http://tools.ietf.org/html/draft-wilde-service-link-rel
from i-d.
The contents
relation originally from html might also be able to do this. I'm curious what others think about that though!
from i-d.
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links says that contents
'Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").'
to me, that's a bit different from "home" itself (for example, at a "home" resource you might even find a link to a "contents" resource), but i am curious to hear more opinions as well!
from i-d.
thinking about the relation of the proposed home
to https://tools.ietf.org/html/draft-wilde-service-link-rel a bit more, it seems to me it's fairly simple: home
links to the actual home resource of the service from where the assumption is application flows start initially; the relations proposed by https://tools.ietf.org/html/draft-wilde-service-link-rel link to where these flows are documented, either in human- or in machine-readable ways. typically, the resource provided at home
might have those links to service documentation and description.
from i-d.
@mnot, any thoughts on this one? if you're ok, i'd be happy to contribute a PR, containing a bit of explanatory text, and the appropriate IANA registration template.
from i-d.
I agree that a home
relation would be useful. It conveys something different from contents
, up
and start
. It would be useful if the text for the registration of the home
relation explained this difference explicitly, I think.
from i-d.
On 2016-06-16 04:18, Asbjørn Ulsberg wrote:
I agree that a |home| relation would be useful. It conveys something
different from |contents|, |up| and |start|. It would be useful if the
text for the registration of the |home| relation explained this
difference explicitly, I think.
link relations are fuzzy by nature so it will be hard to differentiate
these things in a definitive way. but i would certainly try and as
usual, feedback will be very much appreciated.
from i-d.
for now, dret/I-D@3002e1f (the "XML syntax for home documents" draft) is where i have added the "home" link relation type. at least it's somewhere, and i'd be fine to migrate it to the core spec when/if the time seems right.
from i-d.
https://tools.ietf.org/html/draft-wilde-home-xml-04#section-4.3.1
from i-d.
So, what are the actual use cases here? Do you envision it occurring in representations sent to API clients (non-browser), or to browsers, or...?
from i-d.
from i-d.
I think that makes sense.
from i-d.
from i-d.
As a note to this thread: I am using a Well-Known URI for the purpose of finding the home document of a server (/.well-known/home). It has less capabilities compared to a link rel, but has served me well over the years.
from i-d.
from i-d.
PR: #214
from i-d.
however, maybe it would be a good idea to register "home" as a well-known URI? i'll open a new issue for that.
@dret: That sounds like a good idea. Would you say it's okay for that well-known
URI to do an HTTP 301
to i.e. /
for applications where that make sense?
from i-d.
from i-d.
#214 merged; thanks!
from i-d.
Related Issues (20)
- Cookie non-string values
- bikeshed-length header: "decimal" number of octets?
- Add examples, move Appendix A contents to section 3 -- .well-known is being used below / HOT 1
- Link Hint to indicate resource class
- Correct usage of profiles within Link Hints
- Concerns regarding large Link headers with Link Hints HOT 1
- Timing concerns for Link Hints HOT 1
- How to serialize multiple "item" links?
- link-hint: broken link in boilerplate
- Wrong HTTP RFC ref'd HOT 1
- Representations of time based fields HOT 5
- Renaming draft-nottingham-binary-structured-headers to draft-nottingham-binary-structured-fields HOT 1
- Any chance of link-hints and linked-cache invalidation to become an RFC? HOT 2
- Token / key dictionary
- h3 negotiation
- IP reputation links
- Typo: BINARY_STRUCTRED -> BINARY_STRUCTURED
- Cookie-Indices should specify how unexpected values are handled HOT 1
- Cookie-Indices should specify how duplicate cookies are treated
- does available hints allow multiple default setting HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from i-d.