The UPDATE_RESOURCE_PROVIDER_CONFIG API call returns 404 if the specified resource provider does not exist. However, libprocess also returns 404 when the `/api/v1` route is not set up. As a result, a client will get confused when receiving 404 and wouldn't know the actual state of the resource provider config. We should not overload 404 with different errors.
The other codes for client errors returned by this call are:
- 400 if the request is not well-formed.
- 403 if the call is not authorized.
To avoid ambiguity, we could keep 404 to represent that the requested URI does not exist, and use 409 to indicate that based on the current the current agent state, the update request cannot be done because the specified resource provider config does not exist, similar to what a PATCH command would return if certain elements do not exist in the requsted resource (https://www.ietf.org/rfc/rfc5789.txt):
Adapting 409 also makes UPDATE_RESOURCE_PROVIDER_CONFIG symmetric to ADD_RESOURCE_PROVIDER_CONFIG.