On Wed, 22 Sept 2021 at 12:37, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote:
> I'm +1 for the change :) > => OK > > right now we have `JSON.stringify` [1] in some places, and NOT in some > others. I would completely get rid of it :( > => You mean from the request parameter or response parameters ? > it's in request this was the only way I found to pass more than one JSON object as a parameter ... :( (ugly but works) as far as I remember is was most unclear thing in our API Maybe you can point to some others :) > > Thanks > Seb > > > Sebastian Wagner > Director Arrakeen Solutions, OM-Hosting.com > http://arrakeen-solutions.co.nz/ > https://om-hosting.com - Cloud & Server Hosting for HTML5 > Video-Conferencing OpenMeetings > > <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> > <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> > > > On Wed, 22 Sept 2021 at 17:19, Maxim Solodovnik <solomax...@gmail.com> > wrote: > >> I'm +1 for the change :) >> >> And I propose to check the current REST API to be clearer >> for ex. right now we have `JSON.stringify` [1] in some places, and NOT >> in some others >> I would completely get rid of it :( >> >> this particular change is small and will affect 1-2 lines of code in >> Moodle plugin :) >> >> [1] https://openmeetings.apache.org/RestAPISample.html >> >> On Wed, 22 Sept 2021 at 06:11, seba.wag...@gmail.com < >> seba.wag...@gmail.com> wrote: >> >>> It is broken. The problem is the fix will be a breaking change that will >>> require 3rd party integration code to be fixed. Not a big fix, but a fix. >>> Eg the Moodle Plugin requires some minor changes. >>> >>> The workaround is to write some additional wrapper code to make it >>> backwards compatible. Which is also a bit confusing. >>> >>> I also don't understand quite if you answer is pro or contra changing >>> the response. >>> >>> So is your statement: >>> A) Yes, lets fix it to align our JSON response with what the >>> schema/method signature says. We don't like wrapper objects. And I am happy >>> that people have to change their integration code to use newer versions of >>> OpenMeetings. >>> B) No, lets leave it like this for now and we do whatever other >>> additional code we need to write to workaround so that our documentation >>> and schema matches what the actual API responses look like >>> >>> If you could please clarify if you are A, B. Or if you don't mind either >>> way/no strong opinion :) >>> >>> Thanks >>> Seb >>> >>> >>> Sebastian Wagner >>> Director Arrakeen Solutions, OM-Hosting.com >>> http://arrakeen-solutions.co.nz/ >>> https://om-hosting.com - Cloud & Server Hosting for HTML5 >>> Video-Conferencing OpenMeetings >>> >>> <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> >>> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> >>> >>> >>> On Wed, 22 Sept 2021 at 10:59, Ali Alhaidary < >>> ali.alhaid...@the5stars.org> wrote: >>> >>>> Hi, >>>> >>>> We have an old saying 'If it is not broken, do not fix it' ;-) >>>> >>>> Ali >>>> On 9/22/21 12:46 AM, seba.wag...@gmail.com wrote: >>>> >>>> Hi, >>>> >>>> as discussed in the comments section in >>>> https://github.com/apache/openmeetings/commit/4daf7c1f53738cd786dc976114cc5278b4f05f4f#comments >>>> >>>> >>>> we would like to propose a breaking change for the OpenMeetings >>>> Json/Rest API in v7.0.0 >>>> >>>> Problem: JSON response wrapping >>>> Currently CXF-RS is configured to wrap the JSON response into another >>>> object. >>>> >>>> Example: Method signature: public List<AppointmentDTO> range(...) { ... >>>> } (Example taken from >>>> https://github.com/apache/openmeetings/blob/master/openmeetings-webservice/src/main/java/org/apache/openmeetings/webservice/CalendarWebService.java#L111 >>>> ) >>>> >>>> OLD/CURRENT JSON Response: >>>> { >>>> "appointmentDTO": >>>> [ >>>> { >>>> itemXYZ: 123, ... >>>> } >>>> ] >>>> } >>>> >>>> >>>> Proposed NEW/UPDATED JSON Response: >>>> // no wrapping object around it, just return list >>>> [ >>>> { >>>> itemXYZ: 123, ... >>>> } >>>> ] >>>> >>>> Reasoning: The wrapping "{ "appointmentDTO": ... }" should be dropped >>>> from the json response body. "appointmentDTO" is generated but it is not in >>>> any schema definition or method signature. Cause there is nothing in the >>>> method signature that would tell anybody where " "appointmentDTO": [" is >>>> coming from. Other than by testing the API call and finding out by try and >>>> error. >>>> >>>> CXF-RS allows configuring our Web Service to NOT generate that wrapping >>>> element. And turn this behaviour off and just generate the list. >>>> See "dropRootName" in the CXF docs at: >>>> >>>> https://cxf.apache.org/docs/jax-rs-data-bindings.html#JAXRSDataBindings-WrappingandUnwrappingJSONsequences >>>> >>>> *This affects all methods returning a JSON response body (which is >>>> pretty much every API Method)* >>>> >>>> Please reply to this email if you have concerns, questions or >>>> objections. >>>> >>>> Thanks! >>>> Seb >>>> >>>> Sebastian Wagner >>>> Director Arrakeen Solutions, OM-Hosting.com >>>> http://arrakeen-solutions.co.nz/ >>>> https://om-hosting.com - Cloud & Server Hosting for HTML5 >>>> Video-Conferencing OpenMeetings >>>> >>>> <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> >>>> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> >>>> >>>> >> >> -- >> Best regards, >> Maxim >> > -- Best regards, Maxim
