Apollo-link-rest: 404 오류 처리를위한 권장 전략?

에 만든 2018년 06월 06일 · 12코멘트 · 출처: apollographql/apollo-link-rest

REST API가 404 응답을 사용하여 레코드가 존재하지 않음을 나타내는 것은 매우 일반적입니다. 바로 지금 이런 일이 발생하면 결과는 networkError 이며, 이는 기본적으로 Apollo 스택에 의해 GraphQL 오류보다 더 치명적인 오류로 처리되는 것으로 보입니다.

예를 들어 다음과 같은 쿼리를 사용합니다.

query BookQuery($slug: ID!) {
  book(slug: $slug) @rest(type: "Book", path: "book/:slug") {
    name
    author
  }
}

엔드 포인트가 404를 반환하면 의도가 error render prop을 사용하여 사용자에게 치명적이지 않은 오류 메시지를 표시 할 가능성이있는 경우 처리해야하는 네트워크 오류와 함께 거부됩니다. 즉, 이것이 REST 대신 GraphQL 쿼리 인 경우 네트워크 오류로 분류되지 않으며 이러한 방식으로 처리됩니다.

이 문제를 해결하기 위해 404 네트워크 오류를 GraphQL 오류로 변환하는 내 사용자 지정 error-link 검사를 추가했습니다.

forward(operation).subscribe({
  next: result => {...},
  error: networkError => {
    if (networkError.statusCode === 404) {
      return observer.next({errors: [networkError]});
    }
    //...
    observer.error(networkError);
  },
  complete: observer.complete.bind(observer),
});

여전히 개선의 여지가 있지만 문제를 해결합니다.

나는 이것이 apollo-link-rest 에서 어떻게 든 해결되어야하는지 궁금해서 대화를 시작할 것이라고 생각했습니다.

enhancement💡 question❔

출처

marnusw

👍3

모든 12 댓글

좋은 질문입니다. -이 패턴이 문서에 대한 제안으로 추가되기를 바랍니다. 나는 여러 아폴로 링크가 겪는 문제의 종류라고 생각합니다 (아폴로 링크 상태가 떠 오릅니다).

그러나 이것이 ApolloLink의 모든 사용자에게 맞는 답이라고 확신 할 수는 없습니까?

fbartho 에 2018년 06월 07일

😕1 👎1

이것은 현재 모든 http 오류가 apollo-link-rest에서 처리되는 방법입니다.

        if (res.status >= 300) {
          // Throw a JSError, that will be available under the
          // "Network error" category in apollo-link-error
          let parsed: any;
          try {
            parsed = await res.json();
          } catch (error) {
            // its not json
            parsed = await res.text();
          }
          rethrowServerSideError(
            res,
            parsed,
            `Response not successful: Received status code ${res.status}`,
          );
        }
        return res;

사용자가 오류 처리 방법을 지시 할 수있는 대소 문자 일치 기능을 추가 할 수 있습니까?
404 == null 와 같은 일반적인 경우에 유용한 기본 유틸리티를 제공 할 수 있습니다.

paulpdaniels 에 2018년 06월 11일

우리가 소개하는 솔루션이이 링크의 모든 사용자에게 적합하지 않을 수 있다는 @fbartho 의 우려를 공유하는 동안 404 오류가 특히 해로운 경우를 생각했습니다. 테스트에서이 예를 취하면 :

query postAndTags {
  post @rest(type: "Post", path: "/post/1") {
    id
    title
  }
  tags @rest(type: "[Tag]", path: "/tags") {
    name
  }
}

post 가 존재하지 않고 404를 반환하면 전체 쿼리가 네트워크 오류로 실패합니다. 어떤 경우에는 이것이 바람직 할 수 있지만 결과는 다음과 같아야합니다.

const data = {
  post: null,
  tags: [{ name: 'apollo' }, { name: 'graphql' }],
}

이 문제를 해결하려면 @paulpdaniels가 제안한대로 추가 오류 처리를 추가하는 것이 매우 쉽습니다. 4xx 오류를 살펴보면 GraphQL 오류 또는 결과를 null 설정하는 등 특수 처리가 필요한 치명적이지 않은 오류 일 가능성이있는 404 및 400/412/422 (변이) 만 실제로 볼 수 있습니다.

이러한 오류에 대해 고정 된 처리기를 제공하는 것이 합리적인지 아니면 error-link 또는 응용 프로그램에 맡겨야하는지에 대한 의문이 남아 있습니다. 여러 변형 쿼리가 지원되지 않기 때문에 (내 생각에?) 특히 관련성이있는 유일한 현재 짧은 것은 위에서 시작한 404 예제입니다.

구성에 오류 처리기를 추가하는 옵션도 있지만 실제로는 거기에 속하는 error-link 에서 기능을 훔치는 것처럼 보입니다. 또한이 링크의 API를 불필요하게 복잡하게 만들 수도 있습니다.

marnusw 에 2018년 06월 12일

👍1

@marnusw 훌륭한 응답입니다. 기본적으로 귀하의 행동을 구현하는 수정을 지원합니다!

fbartho 에 2018년 08월 21일

142는 404 오류 처리를 추가합니다. 이것이 이번 토론에서 가장 중요하다고 생각합니다.

marnusw 에 2018년 09월 01일

👎2

많은 REST API 표준을 기반으로 모든 오류 코드에는 항상 사람이 읽을 수있는 메시지가 포함되어야합니다. # 142에서와 같이 그 결과를 무효화하는 것은 그와 정반대입니다.

christrude 에 2021년 04월 13일

좋은 REST API 관행과 일치하도록 404를 정상적인 네트워크 오류로 복원하는 PR을 올렸습니다. https://github.com/apollographql/apollo-link-rest/pull/283

christrude 에 2021년 04월 13일

@christrude REST API에 관해서는 동의하지 않지만이 라이브러리의 목적은 REST API가 GraphQL처럼 작동하도록 만드는 것입니다. 따라서 누락 된 리소스에 대한 GraphQL 접근 방식이 null 를 반환하는 것이라면이 라이브러리는 RESTful 404 규칙을 GraphQL null 반환 값 규칙으로 변환해야합니다.

marnusw 에 2021년 04월 13일

@christrude REST API에 관해서는 동의하지 않지만이 라이브러리의 목적은 REST API가 GraphQL처럼 작동하도록 만드는 것입니다. 따라서 누락 된 리소스에 대한 GraphQL 접근 방식이 null 를 반환하는 것이라면이 라이브러리는 RESTful 404 규칙을 GraphQL null 반환 값 규칙으로 변환해야합니다.

그렇다면 GraphQL은 UI에서 404 응답을 어떻게 처리 할 것을 제안합니까? 아무것도하지 마세요? 그래서 요청은 조용히 죽을까요? 그것은 엄청나게 나쁘거나 좋지 않은 UX / api 관리입니다.

christrude 에 2021년 04월 13일

ID로 항목을 쿼리하고 null을 반환하면 그에 따라 UI에서 처리합니다. 데이터가 포함 된 경우 표시합니다.

marnusw 에 2021년 04월 13일

여기 @marnusw에 동의합니다. 사용자의 나머지 API가 수행하는 작업을 실제로 제어 할 수 없으므로 라이브러리가 허용하는 작업이 지나치게 제한되지 않아야합니다. 404 => null 매핑은 상대적으로 직관적 인 의미 체계로 REST의 요청 모델 당 단일 리소스에서 GraphQL의 요청 당 다중 리소스 (클라이언트 관점에서)로 이동할 수있는 동시에 누락 된 데이터가 폭발하지 않습니다.

응답 변환기의 사전 패키지 버전이나 사용자가 http 상태 처리를 완전히 제어 할 수있는 요청 처리 논리의 추상화와 같이이 동작을 옵트 아웃하는 더 좋은 방법이있을 수 있습니다. 그러나 나는 이전 행동으로 되 돌리는 것이 올바른 접근이라고 생각하지 않습니다.

paulpdaniels 에 2021년 04월 15일

접근 방식의 문제 중 일부는 결과 구독에서 404이기 때문에 null 결과인지 또는 콘텐츠 없음 반환 201 또는 이와 유사한 것인지 알 수 없다는 것입니다. 애프터웨어에서이 문제를 수정하여 상태를 확인하고 실제 서버 오류 메시지에 액세스 할 수 없기 때문에 문제를 가정하는 오류를 발생 시키도록했습니다. 특히 제 경우에는 사용자 지정 가져 오기를 사용하여 인증 토큰을 주입하기 때문입니다. , 그리고 apollo가 그것을 삭제하기 전에 응답을 얻는 데 사용할 수 없습니다. 내 솔루션은 한 가지 경우를 제외하고 앱 전체에서 다른 404 응답에 대한 나쁜 담요입니다.

christrude 에 2021년 04월 15일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Apollo-link-rest: 404 오류 처리를위한 권장 전략?

모든 12 댓글

142는 404 오류 처리를 추가합니다. 이것이 이번 토론에서 가장 중요하다고 생각합니다.

관련 문제