These changes are only being discussed Nothing is broken, yet :)))) we can @Deprecate these old methods and/or move it to some prefixed URL so API users will need to change base URL from https://localhost:5443/openmeetings to https://localhost:5443/openmeetings/v1
On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > @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> >>> >>> -- Best regards, Maxim
