ok lets say the photon publishes an event and then a webhook POSTs to my web service and the photon subscribes to the event because it’s looking to get a response back that it needs to use in another function.
now what if my webservice isn’t ready to give me the data because it doesn’t have it yet? like it will but it needs more time. if this is even a possibility then should i POST the request and just receive and status code that the POST worked and then use a separate webook to GET untill the webservice has the data i need? would i have to GET on a loop until it comes in? or should the webservice call a function and pass the data at that time? i feel like because the device is requesting the data it shouldn’t be on the webservice to send it unless as a response… or can my webservice authenticate and publish an event that the photon subscribes to and uses that information when it comes in vs having a function called when really it is waiting on information to proceed. can’t figure out the best practice here… i do think the last option if possible makes the most logical sense… i feel like calling functions when really the device is waiting on data is a bit hackish…
thanks for advice!
So many questions!
Your code would need to be written in an asynchronous manner.
You trigger a request (e.g. via Particle.publish()) and then don’t wait for the reply, but carry on with other stuff.
Only once the reply arrives (e.g. via Particle.subscribe()) you deal with the new information.
This is also how webhooks work.
Hi thanks for your response. Well, there’s nothing else to carry on with until the response is received. So you are saying the webservice will just respond when it’s ready? It’s not a problem that it may not be ready when it gets the request?
No problem what soever.
Particle.subscribe() will hook up the event handler with the cloud which will sit there happily waiting for anybody to throw an event at it.
Then it’ll call the set handler execute and go back to waiting.
Ok but then the web service will put a reply somehere when it’s ready? Or it will just respond to the webhook request when ready? What if it’s like 5 minutes? This wouldn’t timeout?
Is this your own webservice?
If so, then it should fairly quickly reply to the webhook, maybe just with an “ACK” event but it still can issue another event which contains the actual data.
You can either set up two subscriptions for that or choose a subscribtion filter that will respond to both events.
Yes my own service. So it should just ACK and then it should publish an event to the particle cloud?
One more question sorry. What if the photon needs to check for a new response? I don’t want it to use an old response in a new sequence. Will it know somehow or should it check for an identifier?
@ScruffR, won’t the webhook timeout if no reply is received from the server within a certain amount of time?
Yes, I guess it would hence
On the other hand - then a webhook would not be required to start with 
You can add a sequence number or you just don't request new data till you get the previous response. If you'd request faster than the requests can be serviced, you'd sooner or later start losing data anyway.
Hmm a sequence number may solve. We already have a session ID but the sequence could run multiple times in one session.
The request is user initiated and can be issued faster then the request data it’s asking for can be sent. So we will ACK and publish the event with a session ID and sequence id too I suppose.
What if this wasn’t my own web service? I wouldn’t be able to authenticate and publish events. Would the webhook have to run on a loop until the data became available?
The user is making a request and the photon needs to check with the webservice to approve or deny but the webservice may very well not be ready at the time the webhook runs because other factors determine if it can approve or deny
Then you'd have a problem, since a webhook can't cycle but has to respond withing 5sec.
Right but an event could cycle triggering the webhook to keep issuing until the response is what we are looking for
Anyhow it sounds like the most efficient way is for the webservice to publish an event with a unique identifier so it won’t be reused in a new sequence? For example if a new request is issued but again the webservice isn’t ready with a response then the old response won’t be used when a new one is required
Then you might run into the error limit. A webhook is only allowed to fail a set number of times before it gets deactivated as bad citizen in the cloud.