@Ali Alhaidary <ali.alhaid...@the5stars.org> The other alternative to fix the issue AND make it backwards compatible would be to have a /v2 version of the API
So all endpoints would be duplicated to have version /v2 of the API (with maybe some other fixes) and the current API stays the same. But would not receive any improvements anymore/deprecated. But that would be quite a bit of work. But yeah, that is what people do when they want to avoid breaking changes. Need to do versioning. 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 18:10, Ali Alhaidary <ali.alhaid...@the5stars.org> wrote: > We are using OM in production with moodle front end, we can not tolerate > downtime neither with OM or its plugin (that needs fixing, but living > with), and to tell you the truth, I do not see it as 'broken' from that > angle. > > So my answer is B. > > Ali > On 9/22/21 2:10 AM, 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> >> >>
