Hi
> On Jun 11, 2020, at 1:38 AM, Bertrand Delacretaz <[email protected]> > wrote: > > Hi Andy, > > On Wed, Jun 10, 2020 at 7:14 PM Andreas Schaefer > <[email protected]> wrote: >> >> I will try to fit into my use case....I am thinking of having big files or >> images than then later are streamed >> to the caller outside of Sling... > > My current use cases are about small String inputs and outputs, so I > haven't addressed the multi-part and large data thing so far. > > I'm planning to make a release of that servlet helpers module in a few > days along with the GraphQL core that uses it with small amounts of > input and output, but it's fine to add what you need later, I think > that would be useful! That is fine with me. Dealing with output streaming as well as multipart forms need some changes in the Mock Request / Response and that will take some time. Right now I do not have a use case for it. > >> ...Also the current code from GitHub is having the checkStatus() on the >> execute(). I think that having a separate >> method (checkStatus()) is better than having on the execute()... > > I had that first and then moved to checking status as part of > execute() to make sure people don't forget to do that. > > However I agree that a separate checkStatus method makes things more > obvious. I'll re-add that method but add an automatic check for 200 > status before providing any response data to the client, unless status > has been checked already, to make sure status is indeed checked. I am not sure if we should make the check mandatory. If the response is returning a stack trace it might help to understand what is going on and so the response is still valid even if the call failed. So for that I would suggest the following signatures: InternalRequest checkStatus(String … expectedStatusCodes) InternalRequest checkStatus(Integer currentStatusCode, String … expectedStatusCodes) The ‘currentStatusCode’ is set in the checkStatus() with the statusCode from the call. The checkStatus() is accepting a status code when one of the ‘expectedStatusCodes’ matches the current. This way the caller can respond depending on the status code. > >> ...I think we also should support multiple Status to be accepted... > > -Bertrand
