On Thu, Dec 20, 2018 at 8:51 PM Pike, Christopher <[email protected]> wrote:
> I can certainly add appropriate code to remove the field on both ends. I > was more questioning why the type information is necessary as I don't have > a use case where I need the type information specified in the object, so it > is extra unnecessary data IMO. > There is no other way to specify the sub-type of FortEntity in JSON format for the deserialization to work. > > > Try this link > > > > https://github.com/pike1212/fortress-rest-service/blob/master/fortressrestapi.png > > > ________________________________ > From: Shawn McKinney <[email protected]> > Sent: Thursday, December 20, 2018 10:07:30 AM > To: [email protected] > Subject: Re: FC-250 > > > > On Dec 20, 2018, at 7:15 AM, Pike, Christopher <[email protected]> wrote: > > > > • Is there a way to give me permission to accept the PRs from > github? > > Don’t know. I’d post that question to the dev list. > > > > > On Dec 20, 2018, at 7:15 AM, Pike, Christopher <[email protected]> wrote: > > > > • Understand that the fqcn field is automatically included, but > the issue is that clients and servers with different versions of the > FortEntity class are now incompatible. A client with the old version won't > include the field, so the server will fail on de-serialization, or a client > with the new version expects it to be there when de-serializing, so will > fail if the server doesn't provide it. > > We can fix the 2nd problem (client with new version) by adding the code to > handle the attribute to the rest component. > > The 1st problem is going to be tricker. How big of a problem is this, i.e > how many old clients are we talking about? 1, 5, 50, 500? When will they > update to latest? > > From the project perspective (rationale) we want to support JSON for > obvious reasons that extend beyond the new UI Embrasure. Fortress Rest's > usage of Apache CXF makes this change practically seamless, other than what > we’re discussing here. It’s literally flipping a few switches. > > There’s another option, but it’s not pretty. We can add an annotation to > ignore unknown fields in the request. We’d prefer not to go there, but if > there is no other way, it should be considered (as a band-aid). > > That’s why I asked the earlier question. Can we apply a band-aid until > you patch the old clients. > > > > > On Dec 20, 2018, at 7:15 AM, Pike, Christopher <[email protected]> wrote: > > > > • It's been a while since I looked at the fortress REST api, but > it seems more xml rpc that REST. I've attached a screen shot that shows a > high level of how we have our REST api structured. > > I’d say that’s a fair characterization. Fortress REST are merely XML/JSON > wrapped fortress APIs. There’s a one-to-one correspondence between a > Fortress REST service and API. The same entities are passed in / returned > as in the APIs. > > Your screenshot did not come through. Can you post it somewhere? > > Thanks, > —Shawn > > > Kiran
