On Dec 28, 2017, at 19:50, Abhilash Raj wrote:
> PATCH won't fail when running partial updates, but it won't silently drop the
> attributes that it doesn't support. So from client side, there is no real way
> to
> understand when to include that attribute which was added in a later version.
Yes
Simon Hanna writes:
> Up until now I was under the impression that the clients
> (Postorius/Hyperkitty) always require the latest version of core.
We don't require that the client be Postorius or Hyperkitty though.
While in one sense we're not responsible for what third party clients
do *at al
On 12/28/2017 06:19 PM, Mark Sapiro wrote:
On 12/28/2017 08:33 AM, Simon Hanna wrote:
* New keys (and values) can be added anytime
This would make things like exposing new stuff easy. Clients that don't
know about a field can just ignore it.
But that doesn't address the original issue which
Abhilash Raj writes:
> How bad do you think would it be for Core to silently drop extra
> attributes and only use the ones that it needs?
I have no idea what the semantics of that would be. You'd need to
come up with rules about semantics of adding attributes that guarantee
this works as expec
On 12/28/2017 04:50 PM, Abhilash Raj wrote:
>
> How bad do you think would it be for Core to silently drop extra attributes
> and
> only use the ones that it needs?
The problem with that approach is it leads to "I set it in Postorius but
it didn't take effect" kinds of issues.
--
Mark Sapiro
On Thu, 2017-12-28 at 15:25 -0500, Barry Warsaw wrote:
> Abhilash Raj wrote:
>
> > Core's REST API is versioned and any change that break backwards-
> > compatibility
> > cause the version to bump so that clients can take care of that.
>
> The 3.1 version bump happened because there was no backwa
Abhilash Raj wrote:
> Core's REST API is versioned and any change that break backwards-compatibility
> cause the version to bump so that clients can take care of that.
The 3.1 version bump happened because there was no backward compatible
way to handle the UUID as int vs hex string change require
On 12/28/2017 08:33 AM, Simon Hanna wrote:
> * New keys (and values) can be added anytime
>
> This would make things like exposing new stuff easy. Clients that don't
> know about a field can just ignore it.
But that doesn't address the original issue which is that when a new
key/value is added
On 12/27/2017 09:49 AM, Abhilash Raj wrote:
Hi All,
Core's REST API is versioned and any change that break backwards-compatibility
cause the version to bump so that clients can take care of that.
However, one question that I have been thinking about recently is how to handle
additions to REST A
