Yeah mate, though the terrible thing about raising my old thread years later is:
- The documentation hasn’t been updated, and no best practice architecture has been provided.
- A indefensibly naive system is still in place where retries occur when a webservice returns a 500 etc. Eventually bringing down the webservice. The web standards way of doing it would be to terminate the particular webhook that error’d as you know, it could be the webservice saying the device isn’t allowed to make that call.
It’s why I’m moving away to a Google IoT stack.
@d.chauhan my recommendations:
Never return anything but a 200 to Particle, it will eventually DoS your webhooks. Either:
– Only only return 200 status codes, easy to do if you’re using say Google Cloud functions. Put an error message in description, but for the love of god use a 200 code or Particle will blow up.
– Proxy everything through Amazon HTTP gateway, simple reason is you could then use third parties who do sometimes return 500’s like you’d expect to in the 20th century, but then you can force the response code on return traffic within the HTTP gateway status codes mangler.
Use a job system, don’t send notifications etc via your webhook. Register a job to send a notification then return completed. Let your job system handle the actual long processing etc. I use Firebase realtime db in conjunction with google cloud functions.