API: POST /api/v1/devices (add a new device) - result for Unknow GroupID

I specially use wrong GroupID with this request:
POST /api/v1/devices (add a new device)

And I get:
{"error":"invalid_request","error_description":"","error_code":1}
Status: Bad Request StatusText: Bad Request

Is that normal that "error_description" does not saing "unknow GroupID"

btw.

When I do the same but with wrong "remotecontrol_id" then I get appropriate description of the error:

{"error":"invalid_request","error_description":"parameter remotecontrol_Id is required.","error_code":1}
Status: Bad Request StatusText: Bad Request

 

ps.
Ithink this can be considered as an issue or Feature Request, but firstly I want to know others opinions.
But if I have right then MOD please move this to IDEAS forum.

 

Regards,
mLipok , AutoIt MVP

Comments

  • DomLan
    DomLan Posts: 490 ⭐Star⭐

    Hi

    I believe that the response received is still correct.
    From the point of view of a malicious caller, get in response detail that an item does not exist in the database would be fabulous ...

    Correct to deliver the message that a required parameter is absent. No information instead on the presence or absence of an element.

    It 's my opinion

    Regards

    Domenico Langone

    MCSD: App Builder

  • mLipok
    mLipok Posts: 781 ⭐Star⭐

    So you agree that this part of API could work better, and still in coherent way ?

    Regards,
    mLipok , AutoIt MVP
  • DomLan
    DomLan Posts: 490 ⭐Star⭐

    Hi mLipok,

    no I do not agree: I believe that the shape of the response received is still correct.

    Obviously it's my opinion.

    Regards.

    Domenico Langone

    MCSD: App Builder

  • DomLan
    DomLan Posts: 490 ⭐Star⭐

    Hi mLipok,
    ok.. .I think you deserve a more accurate response.

    There is a standard that defines the behavior of applications, such as TeamViewer API, which make use of the BEARER token type. RFC6750 -> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html

    This standard, among other things, also defines the extremes of the negative response when this should occur. Of course, the same logic can and must be applied to subsequent requests because always considered in the field of applications that rely on OAuth2 system.

    When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response:

    • invalid_request
      The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code.
    • invalid_token
      The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request.
    • insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary to access the protected resource.

    If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information.

    The case that you describe corresponds to the first series: the standard does not define the opportunity to provide additional information. When in doubt, those who produce the service, always opt for the last chance offered: never give additional information.

    Best regards.

    Domenico Langone

    MCSD: App Builder