What is the best practice implementing REST API endpoint for value objects? Consider application settings managed by some UI which communicates with REST API. Here the settings is value object. In database it's simply a table of key-value pairs. At the web level I consider it as a DTO transferring keys and values. Now, what's the correct way to define a REST endpoint for such a value object? Is it correct to define only /settings where POST to it overwrites the previous value object (actually the keys carried by the DTO)?
One way to approach this problem is to consider how you would do it on a web site...
We would probably start with some resource (/settings), the returns an html representation of your key value pairs. That representation might also include forms for submitting changes, or you might instead provide links to pages with the forms. To submit a change, the user would navigate to the page with the form, enter the new information, and submit the form. The browser's form processing engine would submit the request as described by the form data/meta-data.
For this use case, we're changing data on the server, so we would use unsafe semantics - aka POST. The target URI can be anything at all, but one choice to take advantage of the standard HTTP caching behaviors is to send the unsafe request back to /settings, so that the previously cached representation is invalidated if the request succeeds.
Alternatively, we could take a remote authoring approach...
Download the /settings page via GET, as before. Then we load the HTML into our local editor, make changes to our local copy, and then PUT our local copy back to /settings, at which point the server can figure out how to make its copy look like our locally edited copy.
If the HTML were large, and the changes were small, we might use PATCH instead of PUT.
One can reasonably argue that HTML is a clumsy way to represent key/value pairs, and that we would rather use something like application/json. For the remote authoring case, that's fine -- when we GET the server we tell it that we prefer the JSON representation, and the rest of the flow is pretty much the same: edit it locally, PUT a copy of our updated representation back to the server, or alternatively describe our changes in a patch document.
In a case where we have to worry about others also submitting changes to the resource, and the lost edits problem, then we might use conditional requests -- copying metadata from the headers of the GET response to the PUT/PATCH request so that the server knows which version of the resource we are trying to replace.