- From: Nicholas Car via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 Nov 2018 00:25:28 +0000
- To: public-dxwg-wg@w3.org
Sure: there's the possibility to use RESTful resource URIs without QSAs, for example you could implement "list profiles" for `/a/resource` with `/a/resource/profile/` etc. as opposed to the QSA `/a/resource?_profile=list` and perhaps implement "get resource by profile" with /a/resource/profile/TOKEN. So a simple pattern of `RESOURCE_URI /profile/ PROFILE_TOKEN` and perhaps `RESOURCE_URI /profile/ PROFILE_TOKEN /mediatype/ MEDIATYPE_TOKEN` if: a) MEDIATYPE_TOKENs don't generate invalid URIs and b) other conneg dimensions such as language can be catered for too, perhaps `RESOURCE_URI /profile/ PROFILE_TOKEN /mediatype/ MEDIATYPE_TOKEN /(language|lang)/ LANGUAGE_TOKEN. The main thing to sort out with this URI-only approach is to order the /dimension/dimension_token pairs. Should it be: `RESOURCE_URI / [PROFILE_PAIR] / [MEDIATYPE_PAIR] / [LANGUAGE_PAIR] / [X_PAIR] ...` or perhaps another order? The order should perhaps follow processing order so that would imply: `RESOURCE_URI / [MEDIATYPE_PAIR] / [PROFILE_PAIR] ...` But I don't know enough about language, time (I think Memento says it's first?) etc. Obviously this purely hierarchical approach is limited compared to HTTP & QSA as it's hard to see sensible URIs doing the equivalent to: `?_profile=xxx&_mediatype=text/turtle,application/ld+json,application/rdf+xml` But loads of sites use, for example, /en/ for English representations of things so I think it's sensible to cater for this. -- GitHub Notification of comment by nicholascar Please view or discuss this issue at https://github.com/w3c/dxwg/issues/505#issuecomment-434891409 using your GitHub account
Received on Thursday, 1 November 2018 00:25:29 UTC