Handle batch data via PUT /models/<guid>

[rhyolight]

The current endpoint at PUT /models/<id> expects the request body to contain a JSON object representing one row of data. This task is to make that endpoint accept many rows of data.

If the JSON object is a list instead of an object, assume it is a list of rows.

Return only the very last result object from the HTM in the response.

[cogmission]

@rhyolight I could see many different sites (endpoints) serving REST requests and acting as a hierarchy of HTM models or Regions? Maybe requests received as a packet or list should aggregate their output and return a list of responses? In this way you could batch-chain many different "processors" eventually; each receiving all SDR outputs? Just an idea... :-)

[rhyolight]

That is a good point, @cogmission, I think I oversimplified the problem. I am going to need to get a result for each row in the batch. @JonnoFTW It should be easy to return a list of serialized result objects instead of just the last one.

[cogmission]

Also, Can you envision each endpoint eventually being able to make REST requests as well as receive them? In that way, you could make a batch request to Endpoint "A" and have Endpoint "Z" make a REST request back to your client which utilizes the output instead of processing a request (i.e. like clienty stuff like graphing or feeding some other application). So the client would make a REST request to Endpoint "Z" which is a Subscription request instead of a "PUT", handing it a URL which it (Endpoint "Z") will use to add to a list of URL's it forwards its REST requests to? That way you could dynamically add "Nodes" in the cloud graph of servers which could process either individual REST requests or act as part of a larger graph of servers which process requests... Just spitballin'

This is all made possible by having the servers be able to invoke REST requests as well as receive them.

[rhyolight]

@cogmission There are strategies for doing that type of thing, but I think it's too early to investigate them now. It should not affect how the basic REST server functionality is established.

[cogmission]

Cool. Just day dreaming out loud... :-)

[JonnoFTW]