@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.
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
>
