It is my experience that control programmers always prefer REST,
because it looks more like an exposed bare API. I would posit that exposed bare
APIs are not necessarily what we want on the web…
"A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
Hi David,
Although I do lean towards REST as well, but – unlike SOAP
and WSDL – there are no proven methods of describing and enumerating REST
endpoints and parameters. i.e. with REST, one has to have a document to code
to; with SOAP, one needs a WSDL and the code is automatically generated.
I do not think we should put SOAP aside. I think it should be
supported as much as REST is supported.
With kind regards,
********************************
Michel
Kohanim, C.E.O
Universal
Devices, Inc.
(p)
818.631.0333
(f)
818.708.0755
http://www.universal-devices.com
********************************
Hi All,
I
added some comments to the document.
With
respect to the REST, SOAP, etc question raised by Ed… I lean a
little toward REST as a starting point. It seems this information is very
“noun”
centric. The participants want to publish information (about a DR event,
etc). The participants (in various markets) should not expect to command
another
participant [i.e. function setYourThermostat() ]. For backward compatibility with
CA
OpenADR,
we can use a separate specification to require any particular SOAP or role-based
interaction (my comments in the document speak to this).
Have
a great day,
Dave
<<energyinterop-wd-00_1_dcw.doc>>
The information contained in this message is privileged and
intended only for the recipients named. If the reader is not a representative
of the intended recipient, any review, dissemination or copying of this message
or the information it contains is prohibited. If you have received this message
in error, please immediately notify the sender, and delete the original message
and attachments.