REST API get item status for only requested items

[GoogleCodeExporter]

1. Feature Description

Now we have these options when requesting data or subscribing for push changes 
via the REST API:
- a single item (or item group)
- an item state
- a single page of a sitemap

It would be very useful if there is one more option - subscribe to get states 
only for a given list of items. The list of comma separated item names could be 
specified in a dedicated HTTP header.

2. Example Use Case

This would make possible to create some extended UI elements, separated form 
the sitemaps logic, as well as will allow to be used some 3-rd party UIs like 
smartVISU.

Original issue reported on code.google.com by mishoboss on 28 Jan 2013 at 7:55

[GoogleCodeExporter]

should be feasible to do

Original comment by kai.openhab on 29 Jan 2013 at 8:29

• Changed state: Accepted

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Any news about this issue?

Original comment by mishoboss on 29 Jul 2013 at 11:32

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Migrated to https://bugs.eclipse.org/bugs/show_bug.cgi?id=423552

Original comment by kai.openhab on 8 Dec 2013 at 8:45

• Changed state: Invalid