You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For resources with multiple representations, what heuristics should nap use to determine which representation to use? Whatever comes first? It probably makes sense to implement some sort of order, much like how browsers have default accept strings for requests – e.g. Chrome sends text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8.
Thinking about this some more it might be useful to prioritize text/html in the accept type, and make it trivial to implement a kind of options html resource that explains the interface of the resource. I think this could be a boon to discoverability, especially if combined with the thoughts in #8 and #22 with regards to registering and looking up resources using the same request mechanisms as anything else. Need some further thought to come up with ideas on what this might look like though.
Currently, nap sets the accept header to
application/x.nap.view
whenever it's not defined. This should change to set it to*/*
instead.The text was updated successfully, but these errors were encountered: