Re: IOTDB worldview vs EVRTHNG

Adding a second mechanism to do the same thing as an existing one but in a
different way is not a convenience to anyone. Almost the entire world of
web services is written on that things (in the abstract sense, but mappable
to the Thing sense) are manipulated by change their attributes, not be
creating change-request-response URLs.

On Thu, Jun 4, 2015 at 2:43 PM, Dave Raggett <dsr@w3.org> wrote:

> It is a question of semantics and convenience, particularly for script
> writers who are used to objects with properties and methods.
>
> On 4 Jun 2015, at 19:29, David Janes <davidjanes@davidjanes.com> wrote:
>
> Why is there _any_ differentiation between 1) updating a property and 2)
> invoking an "action"? As per the email you were replying to, it is a
> complication without _any_ seeming benefit.
>
> D.
>
> On Thu, Jun 4, 2015 at 2:22 PM, Dave Raggett <dsr@w3.org> wrote:
>
>> Here’s my summary of the basics for using REST from my slides on the WoT
>> Framework
>>
>>   Representational State Transfer (REST)
>>
>>    - HTTP GET to retrieve a thing's description
>>    - HTTP GET to retrieve *all* properties of a thing
>>    - HTTP PUT to update *all* properties of a thing
>>    - HTTP PATCH to apply changes to *some* properties
>>    - HTTP POST to invoke actions on a thing
>>    - HTTP POST is also used to notify events
>>       - To proxies or dependent things
>>
>>   REST can also be used with other protocols.
>>
>> These methods and their meaning are described in the HTTP specs, see RFC
>> 7231 and RFC 5789 for the PATCH method
>>
>>     http://tools.ietf.org/html/rfc7231
>>     http://tools.ietf.org/html/rfc5789
>>
>> In respect to using PATCH here is an extract from RFC 5789:
>>
>> A PATCH request can be issued in such a way as to be idempotent,
>> which also helps prevent bad outcomes from collisions between two
>> PATCH requests on the same resource in a similar time frame.
>>
>>
>> The URI paths are really a matter for each server.  For the Web of
>> Things, we would like to decouple scripting from the protocols, as this
>> makes scripting easier, it allows the protocols to be changed as
>> requirements evolve, and it makes it easier to implement highly scalable
>> service platforms.  As a result, developers only need to see the URI for a
>> thing’s description and won’t need to deal with the URIs for the REST
>> services described above.
>>
>> —
>>    Dave Raggett <dsr@w3.org>
>>
>>
>>
>>
>
> —
>    Dave Raggett <dsr@w3.org>
>
>
>
>