Announcement

**Blama** · 3 Nov 2017, 02:43

Hi Isomorphic,

with help from #9 in the old thread I found out that the syntax for multi-request calls is:

Code:

<transaction>
    <operations>
        <request>
            <dataSource>employees</dataSource>
            <operationType>fetch</operationType>
            <startRow>0</startRow>
            <endRow>1</endRow>
            <textMatchStyle>exact</textMatchStyle>
        </request>
        <request>
            <dataSource>employees</dataSource>
            <operationType>fetch</operationType>
            <startRow>2</startRow>
            <endRow>3</endRow>
            <textMatchStyle>exact</textMatchStyle>
        </request>
    </operations>
</transaction>

With this, issue 4) from #1 is solved. Could you add transaction and operations as top enclosing elements in the docs?

Best regards
Blama

**Isomorphic** · 3 Nov 2017, 10:55

Re #2 and #3 these look like ARC is just sending an invalid request. Let us know if you can show that this is not the case.

Re #1 we don't really see an issue that this totally invalid usage results in an Exception.

**Isomorphic** · 7 Nov 2017, 12:49

Re: the docs, RestHandler is documented as handling the RestDataSource format, and the format for multiple requests in a single HTTP request is already well documented, for both XML and JSON, on RestDataSource.

**Blama** · 8 Nov 2017, 00:47

Hi Isomorphic,

Originally posted by Isomorphic View Post

Re: the docs, RestHandler is documented as handling the RestDataSource format, and the format for multiple requests in a single HTTP request is already well documented, for both XML and JSON, on RestDataSource.

OK, thanks. That also explains how I knew about the format in the first place when creating the old thread. Sometimes it is difficult to keep it all together :) (For others finding the thread via search, these are the clientside RestDataSource docs)

Please note that these docs issues are still open, though.

Originally posted by Isomorphic View Post

Re #1 we don't really see an issue that this totally invalid usage results in an Exception.

You are right in the sense that it is an very basic error and also easy to see what the error is from the stack trace.
The reason I bring this up is that in my web application, I can shield the 3rd party end user (=the user of my product) from all nasty DB or server error messages with validators etc.
This also might not be an issue in SmartGWT Mobile apps, as here the application developer also controls the client side code.

In an API, which belongs to a web application, I don't have this chance, at least not at this low level. To a 3rd party integration developer (=user of my product), which will use my API, this won't look too good. I'm pretty sure this is true for all non intranet-only applications that will make use of the RestHandler servlet.
So I guess my point is: "Application end points (GUI for web application, API for application integration) should not display stack traces".

Originally posted by Isomorphic View Post

Re #2 and #3 these look like ARC is just sending an invalid request. Let us know if you can show that this is not the case.

OK, I'll retest this soon and come back if I find something.

Thank you & Best regards
Blama

**Isomorphic** · 9 Nov 2017, 15:43

Again, on the exception for a totally invalid URL - this will be shown to a developer, not an end user. Developers understand exceptions.

**Blama** · 15 Nov 2017, 01:50

Hi Isomorphic,

as follow up to #1 and your answer #3:
#1 2) The error here is that ARC expects JSON data and I did not set

Code:

            <init-param>
[B]               <param-name>wrapJSONResponses</param-name>
               <param-value>false</param-value>[/B]
        </init-param>

Here the <script> header in the RESTHandler answer confuses ARC.

#1 3) I assume the issue was that I did not remove the data from 4) in the body and this caused the error.

So right now I don't have any issues here, but one enhancement suggestion I'll show in the next post.
Regarding #1 1) and the Exception/Error message issue, I'd still think error messages are the better solution, but I'm fine with the way it is as well, because nobody complained so far (to be fair, nobody is using the API as of today :)

Best regards
Blama

**Blama** · 15 Nov 2017, 05:32

Hi Isomorphic,

the enhancement I have in mind is for the "Expanded Raw REST mode URI Syntax". A combination of "Basic raw REST mode" with it would be good, so that this request is possible:

Code:

isomorphic/RESTHandler/<DataSource name>[B][/<operationId>][/B][/<primary key value>]

Then the same rules you mention in "Basic raw REST mode" should apply:

HTTP verbs are handled as follows:

An HTTP GET performs a fetch, with any query params beyond the primary key interpreted as simple criteria.
An HTTP DELETE performs a remove, with any query params or posted data beyond the primary key interpreted as simple criteria.
An HTTP POST performs an add, with both query params and posted data providing the record field content.
An HTTP PUT or PATCH performs an update, with both query params and posted data providing the record field content. However a PUT with no primary key value(s) performs an add, but a PATCH with no primary value values(s) performs a multi-row update, subject to the currently configured allowMultiUpdate settings for updates on that DataSource.

If there is no matching operationId for the operationType determined by the HTTP verb, an error should be thrown.

Please note that these docs issues (a small one regarding "Expanded Raw REST mode URI Syntax") are still open.

Best regards
Blama

**Blama** · 15 Nov 2017, 05:41

Hi Isomorphic,

motivation for #8 is this:
Basically every Application that is more than a showcase will use many operationBinding. If these are not accessible, 3rd party integration developers will quite often need to use the request style from #2 with only the /RESTHandler as URL and all data in the POST body.

If they need to use this format anyway most of the time, there is little use in also teaching them about (=documenting this in my API documentation) the other format, that will almost never be used. I hope this idea makes sense.

Best regards
Blama

**Blama** · 8 Aug 2018, 07:47

Hi Isomorphic,

Originally posted by Isomorphic View Post

Again, on the exception for a totally invalid URL - this will be shown to a developer, not an end user. Developers understand exceptions.

this was now brought to my attention again by a 3rd party that wanted to test the API.
I agree that the information is helpful to a developer, but in general it should be the goal to shield all external parties from exceptions and stack traces and only show error messages, IMHO.
If I now configured Tomcat to swallow all exceptions in order to not to tell much about the system in use and to appear more professional, the external developer would not know what went wrong.

Best regards
Blama

**Blama** · 22 Feb 2019, 05:07

Hi all,

this thread is related.

Best regards
Blama

**Blama** · 22 Feb 2019, 05:51

Hi Isomorphic,

the HTTP code is 200 in this case. Although minor, I'm pretty sure that this is not correct.

Best regards
Blama

Announcement

6.1p RESTHandler issues

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment