On Wed, 22 Sept 2021 at 13:11, seba.wag...@gmail.com <seba.wag...@gmail.com>
wrote:
> @Maxim Solodovnik <solo...@unipro.ru>
> The strange thing about those POST requests is that its a @FormParam. And
> not just a simple request post body.
>
Well
@FormParam was used due to this was the option I was able to find :)))
My goal was to be able to get *multiple* parameters which are POJOs :)))
Maybe this is possible with @BeanParam instead?
I would investigate
This might make our API much better :)
>
> Those methods are POST Methods. So by definition the payload should be
> sent in the POST request body. Makes sense? :)
>
> However a POST Body, only has 1 Body. You can NOT put 2 bodies into 1
> post. This also makes send in terms of RESTFul APIs: POST endpoint creates
> 1 object. Not 2 objects.
>
> But some of our methods have 2 FormParams, for example:
> UserService::getRoomHash(@QueryParam("sid") String SID,
> @FormParam("user") ExternalUserDTO user,
> @FormParam("options") RoomOptionsDTO options) { ... }
>
> 2 form params: ExternalUserDTO user + RoomOptionsDTO options
> => THis won't be able to just put into 1 post body. You would need to then
> again create a "parent/wrapper" object so that its a 1 object, and you can
> have it in 1 post body.
>
> FormParams are still sent in the Post Body. But its different sections.
> They are sent as "multipart/form-data" which is what we currently use. But
> it sets some boundaries so it can decipher the parameters separated. Which
> is actually quite complicated. But that's what we currently do.
>
> The other alternative is to completely specify all params into a long list
> of parameters and eg use "application/x-www-form-urlencoded" but that would
> mean:
> A) You need to do URL encode on the variable before putting it into the
> payload on the client side
> B) On the server side do a URL decode on the variable
> => Also pretty ugly
>
> So I yeah, I think it would be worth resolving this. But ideally we should
> follow the RESTFul guidelines, which say "POST body". But that would quite
> a change to get it done.
> So yeah I also think this would be nice to resolve but unfortunately it
> doesn't seem there is a very simple or elegant way from where we are now ?
>
> 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:52, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
>>
>>
>> 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
>>
>
--
Best regards,
Maxim
