Pending Credits API + Webhooks

[Foxtrek_64]

Please provide an extension to the REST API and (on 2.3) Webhooks to enable third party integrations which can query and modify the credits owned by a forum user.

Use case: I would like to sync the number of credits on my forum to the currency a player possesses in Minecraft. A REST API would enable me to synchronize the number of credits a user has with the amount of in-game money they possess, and enable players to earn money by making forum posts and the like. The webhook integration is exceptionally helpful in allowing me to update the cached amount possessed by each player, such as by knowing the amount of credits that have been added or removed.

I propose the following endpoints, though the exact path may change.

GET /user/{id}/credits - Gets the current number of credits owned by the user
PUT /user/{id}/credits - Set's the current number of credits owned by the user. Also accepts POST if PUT is not available.
POST /user/{id}/credits/modify - Adds the specified number of credits to the person's account. Specify a negative number to subtract credits.

I'm not too picky about design. Providing the user id in the request URI is one option, as is providing it in the JSON body:

{
    "UserId": 1,
    "Amount": 5,
    "FireWebhook": false,
    "nonce": 12345
}

The response should return the user's id and the new amount, regardless of the endpoint. This keeps the model relatively simple. The FireWebhook property can optionally be used to suppress the webhook, which may just be redundant in situations where the API client and the webhook recipient are the same entity. However, responding with a request id of some sort can also help to filter out webhook events where the webhook was fired by an API request.

As for the Webhook event, I think that only two events are needed:
credit.edit - The user's credit was manually set to the specified amount.
credit.update - The user's credit was modified by the specified amount.

Both events would need to send the user's forum id and the amount, like in the json example above. The sign would be sufficient to describe the nature of the update operation, where 5 indicates 5 credits were added and -5 indicates 5 credits were charged/removed.

Known safety checks:

• If a PUT operation specifies a negative amount and the Credit system is set to round negative amounts up to 0, the configuration should be observed, setting the user's account to 0 and returning a current amount of 0.
• If an update operation specifies that 0 credits should be added or removed, two options are available:
  • 200 OK - Successful operation, but effectively a no-op. Just return the user's current amount.
  • 400 bad request - Amount must not be 0
• A nonce value should be accepted to ensure the same request isn't processed multiple times, especially important for update operations.