Behaviour with POST and Accept: application/vnd.pgrst.object+json

[sted]

Environment

• PostgreSQL version: 12.0.2
• Operating system: MacOS 14.4

Description of issue

From Singular test I see that, even if there is not return=rep, we consider a POST to create multiple objects with

Accept: application/vnd.pgrst.object+json

as an error (406).

For instance:

        it "raises an error when attempting to create multiple entities" $ do
        request methodPost "/addresses"
            [("Prefer", "tx=commit"), singular]
            [json| [ { id: 200, address: "xxx" }, { id: 201, address: "yyy" } ] |]
          `shouldRespondWith`
            [json|{"details":"The result contains 2 rows","message":"JSON object requested, multiple (or no) rows returned","code":"PGRST116","hint":null}|]
            { matchStatus  = 406
            , matchHeaders = [ matchContentTypeSingular ]
            }

I think that this is questionable.
I would have imagined that no errors occur if we do not return any objects.
What do you think?

[wolfgangwalther]

What I find really odd about this test is this:

            { matchStatus  = 406
            , matchHeaders = [ matchContentTypeSingular ]

Wait, we say 406, which means we can't accept the contenttype that was asked for. But at the same time... we return exactly this content-type. Shouldn't we return the error message as plain application/json instead?

Compare this to a request for Accept: image/png - are we now going to render the error message as a png image? Surely not - we will still return an error document as json. Hopefully with application/json, too.

[steve-chavez]

Right, I remember running into that odd behavior before. Opened #3373.

[steve-chavez]

This was discussed/decided on #1417. From my POV, it's like HEAD, we shouldn't change behavior because there's no body returned. The server has to obey the rules of the requested representation before any preference is executed.

[sted]

I've been following the engaging discussion in #1417 and came across this comment:

Accept is used for the client to tell the server the set of content-types that it is capable of understanding.
It does not mean that the server must return a response. It just means that if the server does return a response it should be in one of these formats.

I hope I'm not being overly insistent, but this leads me to believe that we were fully honoring the client's intentions by inserting two records without issuing a response with a payload, in line with the principle of least astonishment.

The current situation is as follows:

1. The client requests the insertion of two records.
2. The client informs the server that, should there be a response, it can accept a specific media type.
3. The client does not explicitly request a response, so a standard 201 status with an empty payload would typically suffice.
4. However, the server issues a 406 status, indicating non-compliance with the client's request on the grounds that, had a response been solicited, it wouldn't have adhered to the Accept header's stipulations.

I believe the issue stems from assigning excessive semantic significance to the Accept header with application/vnd.pgrst.object+json.

I understand, however, that it may be too late to change this behaviour.

[wolfgangwalther]

in line with the principle of least astonishment.

I'd be very surprised if the success of my POST request depended on the Prefer: return=rep header. Or, since this is only my preference and not strictly enforced.. if the success of my POST request depended on the server's willingness to honor my return=rep preference.

Thinking this further, the server would have the choice to never return a response in those cases, even if it could, just to avoid the 406 error.

This will quickly be much more complex and confusing than what we have right now.

At least the current handling is consistent.