X-Deja-Vu response should be more helpful

[pond]

Hoodoo understands "expected duplications" via X-Deja-Vu: yes in a request (or endpoint.deja_vu = true if using Hoodoo::Client) but only signals that a duplicate violation exception was returned by the database engine via X-Deja-Vu: confirmed / result.response_options[ 'deja_vu' ] == 'confirmed'.

Very often, callers will want to recover the original resource. Right now the best they can do is hope that the destination resource offers a lookup ability based on the duplicate value - typically a search/filter option in #list - but this opens up extra error conditions and complexity in the API calling code as well as bulking out the API of the destination dupication-detecting resource.

Some options are:

• Return it as the response inline, which is kind of what you'd expect, but it might break clients that simply check for an empty response rather than 204 status code or X-Deja-Vu: confirmed header.
• Return the ID of the item as (say) an additional header, e.g. X-Deja-Vu-Item-ID: <uuid>, which still requires an additional call to look up the data but does mean it's a simple #show.

[davidoram]

In my case there is no in-production code to consider, so it feels more natural if the deja-vu call returns the same thing as the original POST/DELETE would have. Luckily I store a 'call counter' for each call, so I can easily set deja-vu on the 2nd and subsequent calls