Closed GoogleCodeExporter closed 9 years ago
should be feasible to do
Original comment by kai.openhab
on 29 Jan 2013 at 8:29
Hi Kai,
you can assign the issue to me if you like.
Original comment by oliver.m...@gmail.com
on 3 Feb 2013 at 3:35
Thanks, Oliver. Do you have a good idea about the URI syntax for such a
feature? I do not really see a nice and straightforward way...
Original comment by kai.openhab
on 3 Feb 2013 at 8:16
Ok, I think I have a good RESTful solution.
- we need a new URI something like http://localhost:8080/rest/subscribe
- the client can connect with websockets, polling etc. to this ressource
- the client can POST a list of ressources to which he wants to connect
Example POST to http://localhost:8080/rest/subscribe:
/rest/items/Temperature_FF_Office
/rest/items/Temperature_FF_Child
/rest/items/Temperature_FF_Bath
this will add the three items to the broadcaster
- the client can DELETE ressources
DELETE http://localhost:8080/rest/subscribe/rest/items/Temperature_FF_Office
will remove the item from the broadcaster
What do you think ?
Original comment by oliver.m...@gmail.com
on 12 Feb 2013 at 5:35
Do we need the full REST resource or we can POST only the item names?
What about the method I described in the first post? For example make a regular
or suspended GET request or websocket connection to
http://localhost:8080/rest/subscribe and use a dedicated HTTP header to list
the item names you want?
Original comment by mishoboss
on 12 Feb 2013 at 10:23
Any news about this issue? I would like to see implementation that doesn't
differ significantly from what we currently have.
Original comment by mishoboss
on 21 Feb 2013 at 10:05
Hi Oliver,
So the idea is that you could subscribe to any resource on the rest api here
(e.g. also sitemaps or pages)? Sounds very versatile to me.
I am only concerned whether this is an accepted pattern for rest as the
"rest/subscribe" uri is everything but a resource in rest terms. Do you have
any references on the web where it is done similarly? If not, how do other rest
apis provide such subscription possibilities?
Original comment by kai.openhab
on 22 Feb 2013 at 8:20
Hi,
I looked around but I didn't find something similar.
Maybe we can use the existing URIs to cover the requested feature.
Instead of the /subscribe we can use the /items or the /sitemaps urls.
But for the subscription I would prefer to POST the resources instead of a list
in the HTTP header.
Original comment by oliver.m...@gmail.com
on 1 Mar 2013 at 7:34
Hi Oliver.
Why you prefer to subscribe via separate POST request? Is there any technical
reason why this is better than specify the resources in a HTTP header in the
GET request? From client point of view it is more straightforward to subscribe
just with one GET request, like the current subscriptions work. Doing this with
separate POST request would mean on every page change, the client must make
three requests one after another to get current statuses and then subscribe for
changes.
Original comment by mishoboss
on 2 Mar 2013 at 5:18
What I prefer is a Restful way. Misusing a HTTP Header to specify resources is
not a clean solution in my eyes. A GET parameter is possible. I read a lot the
last days and found a good solution in the book "REST und HTTP" by Stefan
Tilkov. He describes a generic batch solution which uses MIME Multipart
Messages to reduce the network connections. I think the book is only available
in german, but I found the same solution in a blog:
http://www.subbu.org/blog/2008/02/rest-and-batch
I think we can easily integrate this in openHab.
What do you think about this?
Original comment by oliver.m...@gmail.com
on 8 Mar 2013 at 4:13
I actually read Stefan Tilkov's book before I designed the openHAB REST API :-)
But I probably spared this chapter as it was of no interest to me at that
time... But anyhow, what he suggests is usually very valuable and thought out.
As this issue won't make it in the 1.2 release, I'd like to slow it down for
the moment - I simply currently don't find the time to think into the details
as I am rather trying to fix some bugs in openHAB :-) But I'll definitely soon
come back on it!
Original comment by kai.openhab
on 9 Mar 2013 at 9:02
I spent some time reading about batch operations with REST and now I fully
understand your point. However I think what we need here are not exactly "batch
operations" (i.e. update one resource, then delete another, then get a third
one, etc. in one HTTP request). What we need here is ONLY getting data, which
is normally achieved via GET requests in the RESTful world. The problem is we
need a way to specify several resources we want to get. I admit that a
dedicated HTTP header isn't the most RESTful way... but it is a solution.
Another solution would be URI parameters, but it is ugly too.
Original comment by mishoboss
on 14 Mar 2013 at 2:51
Any news about this issue?
Original comment by mishoboss
on 29 Jul 2013 at 11:32
Another approach, used in another great open source project:
https://code.google.com/p/iotsys/wiki/HTTPinteraction
Scroll down to section "Using an oBIX watch to monitor an object"
Original comment by mishoboss
on 19 Aug 2013 at 11:56
Could this maybe be solved by implementing similar concepts as the Amazon AWS
SQS (http://aws.amazon.com/sqs/)and SNS (http://aws.amazon.com/sns/) services,
but adapted to OpenHab?
Original comment by edmund.t...@gmail.com
on 27 Sep 2013 at 5:42
Almost a year old issue and still nothing :( Oliver, are you still here? I have
plans for a new version of GreenT and this issue just blocks it.
Original comment by mishoboss
on 1 Dec 2013 at 3:29
Yes, I'm still here. Sorry, for the confusion but I think we didn't make a
decision on how to implement the requested feature. I plan to implement some
enhancements from the new atomsphere version. Maybe it's possible to add this
feature too ;-)
Kai, did you find the time to think about it?
Original comment by oliver.m...@gmail.com
on 2 Dec 2013 at 10:24
Migrated to https://bugs.eclipse.org/bugs/show_bug.cgi?id=423552
Original comment by kai.openhab
on 8 Dec 2013 at 8:45
Original issue reported on code.google.com by
mishoboss
on 28 Jan 2013 at 7:55