rethink url core property

[mwhite]

What is the purpose of having a URL field if it just contains a URL that can be programmatically generated from the facility ID and base API url?

The spec requires the major version number to be exposed in the URL. This would probably result in, if not be expressly be for the purpose of allowing, providers giving access to the same set of facilities through multiple base API urls for clients implementing different major versions of the API. Would the two endpoints return different URLs in a facility response for different API versions? That seems to go against the idea of core properties being canonical data.

I propose we require URL to be to a human-readable representation of the facility if one exists, and otherwise it should be left out.

[bobjolliffe]

On 24 February 2013 21:38, Mike White notifications@github.com wrote:

What is the purpose of having a URL field if it just contains a URL that can be programmatically generated from the facility ID and base API url?

The spec requires the major version number to be exposed in the URL. This would probably result in, if not be expressly for the purpose of allowing, providers giving access to the same set of facilities through multiple base API urls for clients implementing different major versions of the API. Would the two endpoints return different URLs for different API versions? That seems to go against the idea of core properties being canonical data.

I propose we require URL to be to a human-readable representation of the facility if one exists, and otherwise it should be left out.

Agree that url in its present form is looking redundant. I am not too sure what is meant by human-readable or how one could require such a thing but maybe that's not important. I support what I think is Mike's central suggestion which is simply to leave out url from the core properties. It's not adding anything in its present form.

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/42.

[sunbiz]

The point with the URL or a self-link is somewhat useful to make it more RESTy. Hypermedia driven, as the REST thesis suggested a self-link is useful

[bobjolliffe]

I'm not that worried about RESTy ... there I've said it, could be I get shot for that :-)

If it is given that these urls are obliged to follow a template of base part + {id} then you are not adding anything by spelling that out. And what if you did and you got two different urls? If you had a list of these facilities and you were going to render the data as html then you probably would present the hyperlink, and as Mike has said, this is easily manufactured.

Its not something I would lose a lot of sleep over, but my sense is to agree with Mike.

The facility could of course have a home somewhere on the internet, eg. http://www.bobsSnakeoilClinic.ie. I wonder if that is what was meant by the human readable url.

On 25 February 2013 13:10, Saptarshi Purkayastha notifications@github.comwrote:

The point with the URL or a self-link is somewhat useful to make it more RESTy. Hypermedia driven, as the REST thesis suggested a self-link is useful

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/42#issuecomment-14040179.

[mwhite]

(By human-readable URL I meant any human-readable page that the facility registry might have for displaying information about that facility -- this was what DHIS2 was returning for the url property at least at some point).

[bobjolliffe]

OK that's what I thought. Which would be sufficiently rare that it is actually a candidate for an extended optional property?

On 26 February 2013 06:46, Mike White notifications@github.com wrote:

(By human-readable URL I meant any human-readable page that the facility registry might have for displaying information about that facility -- this was what DHIS2 was returning for the url property at least at some point).

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/42#issuecomment-14098090 .

[rowenaluk]

does not apply, duplicate with issue 45