Raising http 400 in Interface-Based Service

tomek · 2019-06-17 15:22:16

Hi
Is it possible to override mormot's response and return Http 400 "Bad request" in Interfaced-based service? (In case if we want to make additional validation of incoming parameters).

Regards, Tomek

EMartin · 2019-06-18 01:24:43

Try:

CurrentServiceContextServer.Error(400,'error message');

I don't remember the exact sintax.

tomek · 2019-06-18 06:40:07

Hi
I've tried, but it doesn't seem to work, it still returns 200:

function TRemoteSrv.Test(aParams: UTF8String): UTF8String;
begin
  //Result := 'Test(' + aParams + ')';
  //ServiceContext.Request.Error('Wrong param value', 400);
  // CurrentServiceContextServer.... no "Error" method
  CurrentServiceContext.Request.Error('Wrong param value', 400);
end;

Regards, Tomek

Last edited by tomek (2019-06-18 06:40:33)

macfly · 2019-06-18 13:48:44

Try (not tested):

CurrentServiceContext.Request.Returns('Wrong param value', 400);

xalo · 2019-06-18 13:50:11

Hi,
If I'm not wrong, the way to return custom response it's via TServiceCustomAnswer record type.
Please check related section in documentation for further details.

macfly · 2019-06-19 18:41:13

I tested it and it really does not work.

At some point of TServiceFactoryServer.ExecuteMethod the status is forced to 200.

60129  Ctxt.Call.OutStatus := HTTP_SUCCESS;

A TServiceCustomAnswer should be used as mentioned by @xalo.

The problem of this in my view is that it loses the standard functionality and it is mandatory to use this type of result.

It may be best to return status 200 and error details in JSON. Something like
{"error": "No validated", "code:" 123}

pvn0 · 2019-06-20 07:56:12

Don't use TServiceCustomAnswer, if you feel like that's what you need then use method based services instead, that will give you all the customization you want.

Instead, like @macfly said, your service defined interface methods should have an out parameter specifying your custom result code :

 procedure DoSomething(const X,Y,Z : Integer; out Result: TResult); // where TResult is an Enum type

Http codes are great for connection, session status, anything else, introduce your own.

ab · 2019-06-20 11:24:57

pnv0 is in the right way, from my point of view.

Ensure you read https://synopse.info/files/html/Synopse … l#TITL_165

In short: for interface-based services, don't rely on HTTP error codes, but define some enumeration types, used to return the state/error of the process.
And set the first enumerate (mapped as 0 in JSON) as "successful state" - this would be the default value, e.g. for mocking.

If you want to have some HTTP status code returned, use method-based services - or TServiceCustomAnswer with interface-based services, but it is not the best pattern just for handling errors, since you would need manual marshalling of the returned JSON, and generate week RTTI information (not good for the documentation, or the client code generation).

tomek · 2019-06-21 06:31:34

Thank you all for tips and possible solutions.
The problem is, that server is made for third party client, and client side developers are quite reluctant to interpreting custom answers with http 200.

Regards, Tomek

Shadownildo · 2019-06-21 14:33:06

tomek wrote:

Thank you all for tips and possible solutions.
The problem is, that server is made for third party client, and client side developers are quite reluctant to interpreting custom answers with http 200.
Regards, Tomek

If i understood it right, you want to do something like this ?

 if FConnection.SetUser(AAuthSettings.GetUSerName, AAuthSettings.GetPassWord) then
  begin
    aStatus := FConnection.CallBackGet(
      'Autentication', [
        'Id', AAuthSettings.GetId.ToString
      ], aOut
    );

    Result := (aStatus = 200);
    case aStatus of
      200:
      begin
        Result := True;
        AMessage := 'OK';
      end;
      400:
      begin
        Result := False;
        AMessage := 'Conection limit!';
      end;
      401:
      begin
        Result := False;
        AMessage := 'Route Blocked';
      end

macfly · 2019-06-21 18:18:31

A proposal to allow return an error status is to use exceptions.
Since a status error is being returned conscientiously, I believe no pattern is being broken.

Something like:

ESynServiceJSONException = class(ESynServiceException)...
   contructor Create(Status, AMessage: RawUtf8; Result : Variant);
end;

Then...

function TRemoteSrv.Test(aParams: UTF8String): UTF8String;
begin
   if not Validated(...) then
      raise ESynServiceJSONException.Create(400, 'Not validated', _Obj(['name','Can not be empty'])); 
end;

Produces

// 400 Not validated

{"result":{
  "name":"Can not be empty"
}}

Last edited by macfly (2019-06-21 18:33:46)

mORMot Open Source

#1 2019-06-17 15:22:16

Raising http 400 in Interface-Based Service

#2 2019-06-18 01:24:43

Re: Raising http 400 in Interface-Based Service

#3 2019-06-18 06:40:07

Re: Raising http 400 in Interface-Based Service

#4 2019-06-18 13:48:44

Re: Raising http 400 in Interface-Based Service

#5 2019-06-18 13:50:11

Re: Raising http 400 in Interface-Based Service

#6 2019-06-19 18:41:13

Re: Raising http 400 in Interface-Based Service

#7 2019-06-20 07:56:12

Re: Raising http 400 in Interface-Based Service

#8 2019-06-20 11:24:57

Re: Raising http 400 in Interface-Based Service

#9 2019-06-21 06:31:34

Re: Raising http 400 in Interface-Based Service

#10 2019-06-21 14:33:06

Re: Raising http 400 in Interface-Based Service

#11 2019-06-21 18:18:31

Re: Raising http 400 in Interface-Based Service

Board footer