Re: IOTDB worldview vs EVRTHNG

__ REST / Actions __ (sorry, gmail won't let me change the Subject:)

Thanks, I get what you're saying I'm pretty sure.

1)

You're still using a verb (changestatus) in the URL. So this is
non-RESTful.

See anti-patterns on this page:
http://www.restapitutorial.com/lessons/restfulresourcenaming.html

2)

You've now created _another_ resource to be monitored - "
http://mydoorlock.com/lock29/actions/changestatus/66373". When do you
dispose of it?

Note that this is another REST violation, as the server has to know that
someone may be interested in what happened due to a request in the pass.
It's not stateless:

http://en.wikipedia.org/wiki/Representational_state_transfer#Stateless

3)

How does a third party know that "http://mydoorlock.com/lock29/
<http://mydoorlock.com/lock29/actions/changestatus/66373>" is being
manipulated at this time? Do I have to list what's at "
http://mydoorlock.com/lock29/actions/changestatus
<http://mydoorlock.com/lock29/actions/changestatus/66373>" and check every
one of the children? If I only get a list of "active request" children,
does the server have to remember I was interested in this in case I check
back to see how they worked out?

4)

Is this not RPC? Does not the resource "
http://mydoorlock.com/lock29/actions/changestatus/66373" represent the
end-to-end request, response, status of a particular action request?

D.


On Wed, Jun 3, 2015 at 8:48 AM, Vlad Trifa <vladounet@gmail.com> wrote:

> Hey David,
>
> I partially agree with this.
>
> I'll rarely need to get the metadata of what properties & co are, so they
> obviously shouldn't be returned every time, and that's why you'd call the
> end-point below only once (to discover it and understand it). Then you'll
> only need to interact with ".../sensors/humidity" directly where you don't
> get that data model anymore - but just the definition.
>
> I'm not OK with the idea that any property and sensor MUST use JSON-LD. If
> we can all agree here on one basic model that is good enough and
> sufficiently flexible to deal with (yes, you are introducing some coupling,
> which you're doing with JSON-LD anyway, and even more so), then I don't
> need JSON-LD.
>
> But I'm obviously OK with the idea that any device can (and even should)
> expose its services with json-id so that it has more flexibility to expose
> metadata & co and more (non-wot) clients can also process it.
>
>
> Now, where I disagree is the "actions" model is RPC and non-RESTful. This
> is most likely because I didn't explain them well, so let's see:
>
> Doing a PUT .../actions/lockdoor is indeed non-RESTful (or worse: GET
> .../actions/lockdoor?lock=true ---> horrible, I know!!), because you're
> putting rpc semantics in the URL. That's bad!
>
> BUT, this is *not* how actions work!
>
> When you do an action, you're creating a REST resource (so you MUST use
> POST), and this resource is a "request to do something" (that might happen
> or not).
>
> The way you'd unlock the door would look like this:
>
> POST http://mydoorlock.com/lock29/actions/changestatus
> {
> "status":"lock"
> }
>
> 202 ACCEPTED  (or 201 CREATED, if instantaneous)
> Location: http://mydoorlock.com/lock29/actions/changestatus/66373
>
> Then you can retrieve this resource any later time and see whether it's
> been successfully executed or not. This has the added advantage that you
> naturally have a buffer where different clients can schedule several
> requests simultaneously (and the device decides when & how to schedule
> those), which is particularly helpful, clean, and RESTful.
>
> I'll happily sit down and watch you demonstrate what's not RESTful about
> this ;)
>
> What do you think?
>
>
> Vlad
>
>
>
> On 03 Jun 2015, at 00:50, David Janes <davidjanes@davidjanes.com> wrote:
>
> So just taking these as examples (make sure to add Accept:
> application/json)
>
> http://devices.webofthings.io/pi/sensors/
>
>   "humidity": {
>
>     "description": "A temperature sensor.",
>
>     "frequency": 5000,
>
>     "name": "Humidity Sensor",
>
>     "timestamp": "2015-06-02T16:06:26.398Z",
>
>     "type": "float",
>
>     "unit": "percent",
>
>     "value": 40.2
>
>   },
>
> From IOTDB's POV, there's a bunch of stuff being mixed together here:
>
> The model, comprising the values: description, type, unit
> The metadata, comprising the value: name, frequency
> The ostate, comprising: timestamp, value
>
> In IOTDB world, the value record would look something like this:
>
> {
>  "@context": "...",
>  "value": 40.2,
>  "timestamp": "2015-06-02T16:06:26.398Z",
> }
>
> @context is JSON-LD magic to provide meaning to "value" and "timestamp",
> defined in the Model (@vocab may be needed too, JSON-LD needs some
> tightening).
>
> The Model is then basically static, and the part that defines value e.g.
> looks like this
>
> {
>  "@id": "#value",
>  "iot:unit": "iot:float",
>  "iot:purpose": "iot-attribute:sensor.humidity",
> }
>
> A lot of those iot: can be taken out, but you get used to it.
>
> Metadata is less frequently changing data and is to taste, but you'll note
> that the value will only reference the Model, not the Metadata.
> Furthermore, Metadata will typically draw it's definitions from the core
> vocab, rather than having to be defined on a case by case basis.
>
>
> D.
>
>
>
>
>