Apollo-link-rest: REST 응답이 비어있는 경우 오류

@isopterix- 지금 당장이 문제를 쉽게 해결할 방법이 없다고 생각합니다. -내 초기 생각은 Fetch를 래핑하고 204 개의 응답 본문을 {} 대체하는 사용자 지정 Fetch 구현을 제공하는 것이 좋습니다

@isopterix 아래 테스트로이 문제를 재현하려고했지만 테스트는 빈 본문에 통과했습니다. 본문이 빈 문자열 인 경우 fetch response.json() 가 {} 반환하는 것으로 보입니다. 오류가 발생하는 위치를 확인하기 위해 라이브 설정에서 더 자세히 추적 할 수 있습니까?

  describe('response parsing', () => {
    it('supports empty response bodies', async () => {
      expect.assertions(1);

      const link = new RestLink({ uri: '/api' });

      fetchMock.post('/api/posts', {
        status: 204,
        body: '',
      });

      const mutation = gql`
        mutation postEmptyResponse($input: String!) {
          newPost(input: $input)
            @rest(type: "Post", path: "/posts", method: "POST") {
            NoResponse
          }
        }
      `;
      const {data} = await makePromise<Result>(
        execute(link, {
          operationName: 'postEmptyResponse',
          query: mutation,
          variables: { input: 'Love apollo' },
        }),
      );

      expect(data).toEqual({
        newPost: {
          NoResponse: null,
          __typename: 'Post',
        }
      });
    });
  });

@isopterix 는 내 마지막 댓글을 신경

빈 본문을 감지 할 때 내가 보는 한 가지 문제는 res.json() 또는 res.text() 를 호출하지 않고 본문에 무엇이 있는지 알 수있는 확실한 방법이 없으며 항상 두 가지 모두를 호출하는 경우도 있다는 것입니다. 불필요한. 그렇지 않으면 Content-Length 헤더를 볼 수 있지만 항상 신뢰할 수 있는지 확실하지 않습니다. 또 다른 옵션은 Content-Type 가 application/json 인 경우에만 JSON을 구문 분석하는 것이지만 일부 API는 모든 응답과 빈 204 응답에 대해 해당 헤더를 공통으로 설정할 수도 있습니다.

나머지 링크는 300 이상의 상태 코드에서 networkError 를 생성하므로 응답 구문 분석은 2xx 상태 코드를 올바르게 처리 할 수있을만큼 충분히 전문화되어야합니다. 다음과 같이 합리적으로 예상 할 수있는 것들 중 :

• 200 OK
• 201 생성됨
• 202 수락 됨
• 204 내용 없음
• (다른 사람?)

204 응답은 본문이 비어있는 유일한 응답이어야합니다. 상태 코드를 검사하고 204 일 때 기본 {} 반환하는 옵션일까요? 매우 구체적인 엣지 케이스에 대한 테스트이기는하지만 라이브러리가 HTTP 표준을보다 잘 준수하도록 만들 수 있습니다.

@fbartho 이러한 접근 방식 중 하나를 선호합니까? 이 옵션 중 하나 또는 그 조합이 합리적으로 들리면 PR을 할 것입니다.

여기에 중간 길이 있을까요? 두 가지 행동을 모두 지원할 수 있습니까?

저는 204를 기본적으로 {}로 해석하는 것을 매우지지합니다. 또는 "null"이 JSON의 내용이없는 의미에 해당하는 null로 간주됩니까?

빈 본문의 업스트림 GraphQL 해석이 작동하려면 {} 를 반환해야합니다.

data: {
  __typename: "...",
  NoResponse: null,
}

"두 행동이 모두 지원 될 수 있습니까?"라고 말하면 204 상태 코드를보고 헤더를보고 있다는 뜻입니까? Content-Length 가 실제로 존재하고 0 있을 때이를 빈 본문의 또 다른 표시로 취하고 기본값을 반환 할 수 있습니다.

이전에 Content-Type 헤더를 제안했지만 json 이외의 것으로 설정되었을 때 수행해야 할 작업에 대해 정확히 알 수 없습니다. 이 헤더를 해석하려면 제안 된 bodySerializer 과 유사한 responseSerializer 구성 옵션을 사용하여 수행해야 할 것입니다. 그것은 아마도 과잉이며 특히 빈 본문 문제를 해결하지 못할 것입니다.

204 및 Content-Length 구현을 수행하게되어 기쁩니다.

지금까지 이전의 조언을 따랐고 204 응답을 처리하기 위해 사용자 지정 가져 오기를 구현했습니다. 하지만 적절한 응답을 받기가 어려웠습니다. 이 기능을 즉시 사용할 수있는 옵션이 있으면 멋질 것입니다.

불행히도 나는 여전히 JS 세계를 탐색하는 방법을 배우고 있습니다.

# 111을 통해 수정되었습니다!

단! 대단히 감사합니다.

이제 작은 문제가 하나만 남아 있습니다. :) 내 임시 솔루션을 개발 한 직후 대상 SharePoint Server의 REST API에 또 다른 문제가 발생했습니다. 항목을 삭제하면 200 개의 응답이 표시됩니다. 본문 내용 없음 :)

즉, "NoResponse"태그로 응답하는 본문 내용이없는 경우 동작을 잠재적으로 일반화 할 수 있습니까? 내가 착각하지 않는다면 패치는 현재 204 특수 사례만을 다룬다.

@isopterix 서버가 Content-Length 를 0으로 올바르게 설정하면 200 개의 응답에서도 작동해야하며, 그 의도도 확인하는 것입니다.

회전을 기대합니다.

내용이 비어있는 성공적인 응답을 처리합니까? 내용이없는 200처럼?

예. 이를 위해 병합 된 수정 프로그램은 204 상태 또는 Content-Length: 0 헤더를 확인하고 빈 개체를 반환합니다.

Content-Length 헤더가없는 200 개의 빈 응답이있는 경우 본문이이 검사를 위해 구문 분석되지 않으므로 작동하지 않습니다.

@isopterix 이것이 작동하는지 확인할 수 있습니까? 나는 200 상태와 Content-Length: 0 을주는 돌연변이를 시도하고 있습니다. 그러나 여전히 Network error: Unexpected end of JSON input 받고 있습니다. 버전 0.7.0을 사용하고 있습니다.

내 브라우저가 실제로 헤더를 표시하는 동안 apollo-link-rest 디버깅 할 때 응답 헤더가 비어있는 것을 확인했습니다. apollo-link-rest 는 응답 객체의 헤더를 조작 / 재설정합니까?

Apollo-link-rest는 @dljcollette 응답 헤더를 조작하지 않습니다! 도움이되는 희망

나는 같은 오류를 만난다

본문이 비어있는 상태 200에 대한 해결 방법이 있습니까?

@thomaszdxsn 이를 수용하는 유일한 방법은 res.json() 대신 res.text() 사용하고 JSON.parse() 구문 분석하기 전에 유효한 JSON을 확인하는 것입니다. 즉, 스트리밍 JSON 구문 분석이 느슨해 지므로 수행 할 가능성이 없습니다.

가장 좋은 해결책은 API를 변경하여 본문이 비어있을 때 의미 상 올바른 상태 코드 204를 사용하거나 200 응답 본문에 무언가를 반환하는 것입니다. 응답 본문에 유효한 JSON 인 것이 있으면 빈 JSON 인코딩 개체도 작동 할 것이라고 생각합니다.

실제로 API를 변경할 수없는 경우 사용자 지정 fetch 함수를 apollo-link-rest 에 전달할 수 있습니다. 결국 ALR을 처리하기 위해 반환하기 전에 응답을 검사하고 변경할 수 있습니다. 해킹이 될 수 있지만 당신에게는 효과가있을 수 있습니다.

또는 다시 API가 응답에 Content-length: 0 헤더를 반환하는지 확인합니다.