Clarify / enhance use case upsert of objects

[alexgordtop]

The api currently supports only creation and update of objects.
In some cases, a user application (UA) wants to push some data into a repository, regardless, if the data is already there or not - a typical upsert - e.g. for status information.

Implementing that case results currently in errors - because there is no way to implement it without getting errors. Having a clean process monitoring in mind, that is an unsatisfying situation.

State 0: No objects present
-> UA has to call POST

State 1: Objects already present
-> UA has to call PUT

=> BUT - there is no way for the UA to check, if there is already an object present - without creating 404s that appear in the logs. And posting data, when the objects are already present, results in 409s - which doesn't help either.

From my point of view, there are several options available:

• Allow a GET request to pass a hint, that it's just a test and missing data is no error (shouldn't be logged as client fault)
• Relax PUT request to create an object, when it doesn't exist
• Add a kind of GET //exists -> true / false to the API

[mjacoby]

I support this idea. This is also in line with latest HTTP semantics in RFC 9110

9.3.4.

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content.

However, I do not understand the problem in hand with the current way things work and logging. Logs should not be relevant for a program to work correctly, i.e., should not cause any functional problems. It is also unclear if we are talking about client or server-side logs. On client side you should even be able to handle those cause with a special cause and not log these kind of "errors" if that is what you want.

In summary, I says we should address this but I do not see this as critical but rather nice-to-have.

[alexgordtop]

I'm talking about server logs. I'm trying to monitor server logs and create statistics about failed requests.

For the client, everything is fine:
The client knows about the fact, that it's trying to clarify the situation (Object of interest present in db or not) and can handle it accordingly.

For the server it's unclear, if an expected / required resource is not found or if the client is just testing, if the resource is present or not. Think about 100 objects, a client would like to maintain on startup (updating status, etc.). It will most probably result in 100 errors in the server log, as long as non successful requests are tracked.

It's not a functional problem - it's a monitoring / observability / usage control inconvenience.

From operational point of view it's of interest, if there are 100 or 100.000 failed requests per hour. That's why I would like to have a kind of "EXISTS?" endpoint - that results in no failed request log-entry, when the requested object is not present.

[mjacoby]

I would argue that this is default and intentional REST behavior and you just cannot know the client's intention on server-side.
Also, returning 404 should not cause an error (like printing the stacktrace to log) but is a valid API response as any other.

The problem seems to occur because you want to "debug"/monitor you client application on server-side which seem like a proprietary issue. There could be multiple proprietary solutions to this, e.g. using HTTP HEAD instead of GET to test if a resource exists from your client or using some custom header for those probing requests.

I would like to have a kind of "EXISTS?" endpoint

From client side this already exists with the regular GET, 200 = it exists, 404 = it doesn't

[alexgordtop]

TF API - 2025-05-08:

• Relaxing the PUT endpoint is the preferred solution, but further investigation of the old strategy should be done until next meeting.

[sebbader-sap]

Fixed with #454