Voyager-Two
commented
6 years ago Hello,
This would reduce the effect of edge cases where the trade being sent goes thru, but something goes wrong before the client gets the response.
Then the client can try to send the offer again and it should say it already exists.
I'm not sure I understand the exact use case for this feature.
Consider allowing the users of the api to provide a key for the trades sent. I'm not suggesting you replace the internal trade id with this, just allow submitting an optional parameter.
This would reduce the effect of edge cases where the trade being sent goes thru, but something goes wrong before the client gets the response. When that happens, you have no way to know that the trade was actually sent. Now you could of course fetch the trades, look at who's the recipient and the items in the trade and then connect the pieces, but could be made much more streamlined if the api consumer is able to provide the identifier that they could have store before they attempt to send the trade.
If you also make it possible to enforce uniqueness of said key, that too would add usefulness of the feature.
Not a deal breaking or mind blowing feature, but I'm sure it would be very useful. You could use the message field for this, but I don't think it's optimal. The recipient of the trades has no use for the id.