Handling POSTed data from forms

@Gordon, comparing your solution with mine, I notice a change in flow when acting on a request. I assumed the example responds to the post request when done with receiving all data for the request and processing it and only after that writing the response... oops... how mistaken I was. No matter what, the common behavior of (post) request and response is receiving the whole (post) request, do the processing, and only after completion - successful or failed - return the response, because the processing may have an impact not only on particular data but also on the level of the whole response for HTTP request, such as the HTTP status response code (200,500,etc).

@user92178, my example is not doing what it is supposed to do, because the response is created prematurely (for various reasons). If you go the route of my version 1 - storing the post data - I prefer storing the individual data - led1, led2 - separately from the requestData... because multiple different posts may update different sets of data, and the way it is built right now is that post handling blows away all data. If you do not want to store the data individually, you can create a separate object and update it with what the various posts provides.

For things like the LEDs though, I prefer solution approach 2, which reads the actual status of the LEDs (hardware), because some - other than post - event and process may change the LED status and the response / storedData will differ from reality... Therefore, in the template, use, for example, digitalRead(LED1) instead of postData.led1. With that you get always the actual status of the LED in the response upon a request - no matter whether get or post - and not some out of sync posted data.