- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Thu, 11 Feb 2016 11:51:14 +0000
- To: "Maik Riechert" <maik.riechert@arcor.de>, "Maxim Kolchin" <kolchinmax@gmail.com>, "Markus Lanthaler" <markus.lanthaler@gmx.net>
- Cc: "Hydra" <public-hydra@w3.org>
February 11 2016 11:28 AM, "Maik Riechert" <maik.riechert@arcor.de> wrote:
>
> You mean @type instead of @id for the views I guess.
>
Of course :).
>
> I guess the question is whether it would be advantageous to define these
> details also individually, because otherwise you will end up creating
> a bunch of types for various APIs and you would essentially end up with
> hard-coded APIs again
These template types would be just as hardcoded as link types are. It would be necessary to include some description in the ApiDocumentation of course and we may decide on the details there. Other than that the client mustn't be hardcoded at all. Client unaware of precise meaning of "ExactSensorSearch" or "AreaSensorSearch" would still be able to provide UI and build valid view URLs. A simplest solution would involve a human-readable description so that the user can choose the view he's interested in. In such case the template type is not required at all:
{
"@id": "/sensors",
"view": [
{
"@type": "ViewTemplate",
"template": "/sensors/exact{?lat,lon}",
"description": "Find sensors at precise location"
},
{
"@type": "ViewTemplate",
"template": "/sensors/around{?lat,lon,radius}",
"description": "Find sensors in surrounding area"
}
]
}
It is important to decide whether we're talking about user agents or autonomous clients. The latter would be great but it's been effectively a holy grail. Haven't service discoverability attempts to date all failed miserably? I'm afraid that Hydra will follow such path if we're too ambitious.
Best,
Tom
Received on Thursday, 11 February 2016 11:52:14 UTC