apollo-link-rest: Handling error response

Hello, I have this Sign-in API which will take request body as:

{
    "authentications": {
        "emailAddress": "name@gmail.com",
        "password": "11111111"
    }
}

The server return token if success:

{
    "authentications": {
        "token": "eyJhbGoiU3RvcmUifV0sImNyZWF0ZWRBdCI6IjIwMTgtMDktMTZUMTg6NTA6NTYuNT"
    }
}

In case email or password input is incorrect, it will return:

{
    "message": "Cannot find document for class 'User'. searched with parameters: '{\"emailAddress\":\"name@gmail.com\"}'",
    "errorCode": 1103,
    "status": 404
}

I can successfully sign-in with a GraphQL schema like this:

gql`
  fragment Authentications on any {
    emailAddress: String
    password: String
  }

  fragment AuthInput on REST {
    authentications {
      Authentications
    }
  }

  mutation signIn($input: AuthInput!) {
    authPayload(input: $input) 
      @rest(type: "AuthPayload", path: "/api/v1/authentications", endpoint:"UsersService", method:"POST") {
      authentications @type(name:"Auth"){
        token
      }
    }
  }
`;

My question is how can I get the response in case of error (wrong email/password) ? Because right now if server return error, the response is always null:

Object {
    "data": Object {
        "authPayload": null,
    },
    "errors": undefined,
}

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 17 (1 by maintainers)

Most upvoted comments

I’m also stuck on this issue. Is there a reason for not returning the full 404 response instead of null?

SajidQ on Apr 3, 2019

@anasnain:

In javascript it would look something like this:

export async function customFetch(requestInfo, init) {
  const response = await fetch(requestInfo, init);
  if (response.status === 404) {
    throw new Error("404 File Not Found"); // Customize this however you like!
  }
  return response;
}

(In TypeScript it would be a little more verbose)

fbartho on Aug 10, 2020

Is the thinking that 404 Not found could describe a data query that successfully, correctly yields the empty set?

It could also signal that the service owners made such a breaking change that a previously-available endpoint has disappeared.

I think the first case could better be handled by 200 OK along with an empty or null application entity. At least, it seems like these two cases should be readily discernable by the client, as they are very different.

cmonacaps on Oct 9, 2019

I have yet to run into a case where not treating 404 as an error has helped me, I keep trying to find nice way to work around that fact.

williamboman on May 21, 2019