Rewrite api's to use POST/PUT/PATCH/DELETE about wlanthermo_esp32_software

[galadril]

So the correct implementation of an api should be:

POST > full json payloads (adds an item to the list).. (!not updating data!)
PUT > full json payload, updates items (!not adding new data!)
PATCH > partial json payload, updates items (!not adding new data!)
DELETE > deletes an item from the api

more info here:
https://jsonplaceholder.typicode.com/

[sochs]

Thanks for your idea. But, what should the benefit be? The settings are not edited constantly and the traffic is already very low. In addition, POST is universal.

[galadril]

"what should the benefit be?"
When you build an api, your building for the future benefits. Other developers that are going to consume your api and work with your data. You can't know whats needed in the future or not, so thats why there are standard definitions for building api's.

For example, I'm now looking into integrating this api into Domoticz, and I found that to set the pitmaster mode, the documentation tells me to upload the full json object, but I dont want to retrieve the latest json, just to update one value (pitmaster mode).

Also if you have the standard protocols in place, i would never look at POST for updating values.. I would always use PUT or PATCH to update full or partial. Developers are always quick, and always take too few time in reading documentation. So building stuff that's standard eases the use and speed of development.

I'm actually most of the times on the consumer side of an api, and I know that using correct api principles are going to be a benefit for the long run.

[galadril]

Im not complaining btw, its just a though of me on how to improve on the api setup

[sochs]

"Im not complaining btw, its just a though of me on how to improve on the api setup"
Don't worry, I just wanted to know the background.

"For example, I'm now looking into integrating this api into Domoticz, and I found that to set the pitmaster mode, the documentation tells me to upload the full json object, but I dont want to retrieve the latest json, just to update one value (pitmaster mode)."
There's a point behind it: it is not intended that single pitmaster values are changed. The Pitmaster is a unit and is only changed in one piece. PATCH would not be available here anyway, only PUT (instead of POST, with same JSON body).
Similar to the channel settings: a channel setting is always transferred at least with the channel number. This would leave only PUT with the transfer of a complete embedded channel object in order to remain in the API standard.
With SYSTEM or IOT parameters, PATCH would be possible.

"and I know that using correct api principles are going to be a benefit for the long run."
I basically agree with you, so thanks very much for the hint. Adding PUT/PATCH next to POST as request method wouldn't be the problem, but it would not change the current internal processing of requests. They are provided as specified in the documentation. This would also be the case with PUT/PATCH.