This would be good for me. I have customized the moodle  module and have just about every API working.

On 22/09/2021 07:13, seba.wag...@gmail.com wrote:
@Ali Alhaidary <mailto: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/ <http://arrakeen-solutions.co.nz/>
https://om-hosting.com <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 <mailto: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
    <mailto: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/ <http://arrakeen-solutions.co.nz/>
    https://om-hosting.com <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
    <mailto: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
        <mailto:seba.wag...@gmail.com> wrote:
        Hi,

        as discussed in the comments section in
        
https://github.com/apache/openmeetings/commit/4daf7c1f53738cd786dc976114cc5278b4f05f4f#comments
        
<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
        
<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
        
<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/
        <http://arrakeen-solutions.co.nz/>
        https://om-hosting.com <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>

Reply via email to