FortEntity really just provides some common fields for every entity correct (modId, modCode, sequenceId)? When do you make a request for some fortress data where you don't know what type will be returned? Or does the api just treat everything as a FortEntity?
________________________________ From: Kiran Ayyagari <[email protected]> Sent: Thursday, December 20, 2018 10:25:52 AM To: [email protected] Subject: Re: FC-250 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpike1212%2Ffortress-rest-service%2Fblob%2Fmaster%2Ffortressrestapi.png&data=02%7C01%7Cclp207%40psu.edu%7C43f23ce52e8d42187d5608d6668f771b%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636809163699525418&sdata=GLLSu4JIGHRQDNDgVskDltRzW8St7HxKWC5vpKXkLr8%3D&reserved=0 > > > ________________________________ > 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
