Question | Sync with buffer using REST API? about cppagent HOT 2 CLOSED

The current at parameter must be between the firstSequence and the lastSequence. You can do a current or sample and get the firstSequence number and then issue a current?at={fistSequence}. I would advise against this since by the time you start streaming with sample?from={nextSequence}, the beginning of the buffer most likely has already moved.

Currently, current?at=0 is not supported; the data will probably no longer be present unless the system is completely idle. If you started a certain distance from firstSequence, e.g., +1000, compute the observation rate and the latency between requests and then add that plus some slop to make sure.

Unfortunately, there is no easy way with a store and forward service to ensure the buffer's beginning stays in place between calls. This would go against the RESTful architectural model and state management. That is why we defaulted current to the end of the buffer since it provides the latest snapshot–similar to the only mode protocols like MQTT operate in without history.

I'd like to know what you're trying to do from an application point of view. Developing a creative solution that still abides by a RESTful architecture and solves your problem is possible. It may be a general problem others are having, and having a standardized solution could be useful.

from cppagent.

I'm improving the way my app synchronizes to the agent buffer for the first time (when adding a connection to an agent for example), taking advantage of the data the agent has in the buffer. Previously I was simply starting at the end of the buffer, a /current request.

Now I'm using a similar process to what you describe in the second paragraph, finding the first sequence number and computing an offset.

If you started a certain distance from firstSequence, e.g., +1000

I guess I was curious about finding the sequence number of the first observation in the buffer. Any MTConnectStreams document will have the buffer stats in the header, I was thinking that since I only need the firstSequence, it would be optimal to form a request that minimizes data transfer beside that; probably over thinking it. I ended up using /sample?count=1 which returns only the first observation. Granted, with only one observation, I can't compute the update rate, so thanks for pointing out that concept.

I understand the intended sequence of calls now; I'll write it out for future readers.

1. /sample to get the first 100 observations, allowing you to estimate the observation update rate (which will vary some, over time). Use the count parameter if you don't like the default behavior of 100.

2. /current?at=<firstSequence+offset> to get an initial state for every dataItem in the device model.

3. '/sample?from=<firstSequence+offset+1>' to start getting deltas from the initial state found in (2).

4. Continue streaming data by issuing /sample?from=<nextSequence> until you get a document header that has nextSequence > lastSequence.

from cppagent.