You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @aidan-casey! Okay, I see there is still an open item for patch support?
I think there are two approaches to this:
Caller makes an explicit decision every time on using PUT/PATCH (e.g., update(), updatePatch())
Lib makes a runtime decision based on count of supplied attributes vs total possible attribute count
Correct me if I'm wrong, but the only time we must use a PUT is if we want to unset a value in Autotask, meaning we have to use a PUT with an empty value in an attribute.
Before digging in too deep, will the lib reject if we supply an entity to update() that is missing some/most of the attributes? I haven't looked at your validation code in a while. If you are explicitly throwing an exception on that, I would understand. Perhaps we could supply an option like enablePatch=true on the update() which would let the lib decide if it wanted to use a PUT or PATCH?
I'm trying to reduce changes to your API while supporting PATCH updates as transparently as possible.
The text was updated successfully, but these errors were encountered:
Currently the update method requires a fully filled out entity, including any properties required for a create request. Any properties unset or changed will attempt to be unset or changed in the request. In this sense, a PUT request basically equates to a replacement, consistent with the PUT specification.
Since most users of this package are retrieving an entity prior to updating it, I was of the mind to defer this to the next version with an API change of update being a PATCH request and replace being a PUT request. This helps ensure the most efficient method is chosen as well.
The problem with trying to support this on the existing update method is that we need a way to only accept some of the properties. This isn't very doable with a DTO since we are requiring certain properties.
I don't necessarily have a specific solution for this version, but I am open to suggestions. 🙂
Hey @aidan-casey! Okay, I see there is still an open item for patch support?
I think there are two approaches to this:
Correct me if I'm wrong, but the only time we must use a PUT is if we want to unset a value in Autotask, meaning we have to use a PUT with an empty value in an attribute.
Before digging in too deep, will the lib reject if we supply an entity to update() that is missing some/most of the attributes? I haven't looked at your validation code in a while. If you are explicitly throwing an exception on that, I would understand. Perhaps we could supply an option like enablePatch=true on the update() which would let the lib decide if it wanted to use a PUT or PATCH?
I'm trying to reduce changes to your API while supporting PATCH updates as transparently as possible.
The text was updated successfully, but these errors were encountered: