Re: Brooklyn REST API - omitting fields in JSON objects

Hi all. I opened a PR for option 2[1] which is very small, that's a good thing I guess. Best. [1] https://github.com/apache/brooklyn-server/pull/889 On Wed, 8 Nov 2017 at 13:16 Robert Moss wrote: > Agree now is the best time to do this. > > Robert > > On 8 November

Re: Brooklyn REST API - omitting fields in JSON objects

note previously we were inconsistent, with NON_NULL used some places, NON_EMPTY elsewhere, and no exclusions elsewhere, and in many places without much thought. so we have three options: 1 - dogmatic - remove all `@Include(NON_*)` annotations 2 - compatibility-first - restore anything

Re: Brooklyn REST API - omitting fields in JSON objects

Alex, All for reducing the rest payload size But agree with Geoff this is a major breaking change for our clients so should adhere to our deprecation policy *Mark McKenna* *Twitter ::* @m4rkmckenna *Github :: *m4rkmckenna

Re: Brooklyn REST API - omitting fields in JSON objects

Hello, I agree with Thomas here. This seems like an API breaking change, and should be reserved for V2 if it at all. I lean towards reverting. Regards, Graeme On 8 November 2017 at 10:01, Thomas Bouron wrote: > Hi all. > > I'm not a fan of excluding fields

Re: Brooklyn REST API - omitting fields in JSON objects

Hi all. I'm not a fan of excluding fields from the JSON payload, if empty, for few reasons: 1. this is a breaking change for the UI and CLI which will be time consuming to fix (very fiddly to guard against this in JS for example) 2. this makes it harder to design clients, because you need to

Brooklyn REST API - omitting fields in JSON objects

Hi All- Until recently our REST API returned full records in most cases, including often lots of empty lists and maps and sometimes nulls -- such as `constraints: []` on all config keys. The widespread preference in REST / JSON community seems to be to omit these unless there is a very