apollo-link-rest: Error when REST response is empty

I have a mutation request which when successful responds with a 204 “No content” status. When coupled with apollo-link-error I am constantly getting a network error: Unexpected end of JSON input.

It appears that apollo-link-rest is trying to parse the empty body of the response.

Any ideas how to mitigate this? BTW I am trying to talk to a SharePoint REST api, so there is not much I can to tweak the server’s response.

There should be a way to tell the apollo-link-rest how to deal with an empty response…

My mutation call:

                  <Mutation mutation={M_WRITE_PROJECT_DETAILS}>
                    {(writeProjectDetails, { data }) => (
                      <Form.Button
                        content="Save"
                        onClick={() => {
                          const token = localStorage.getItem("token");
                          writeProjectDetails({
                            variables: {
                              projectId: project.Id,
                              input: {
                                __metadata: {
                                  type: "SP.Data.ProjectListItem"
                                },
                                Title: project.Title
                              }
                            },
                            context: {
                              headers: {
                                "X-RequestDigest": token,
                                "X-HTTP-Method": "MERGE",
                                "IF-MATCH": "*"
                              }
                            }
                          });
                        }}
                      />
                    )}
                  </Mutation>

The corresponding gql query:

const M_WRITE_PROJECT_DETAILS = gql`
  mutation writeToSPList($projectId: String, $input: String) {
    writeToSPList(projectId: $projectId, input: $input)
      @rest(
        type: "Project"
        path: "/web/lists/GetByTitle('Projects')/items(:projectId)"
        method: "POST"
      ) {
      NoResponse
    }
  }
`;

“NoResponse” is obviously null since there is no response, but then again I cannot send a mutation without any response fields… unless I am missing something.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 18 (7 by maintainers)

Most upvoted comments

I think in order for the upstream GraphQL interpretation of the empty body to work we should return {} which will then result in

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

When you say “Could both behaviors be supported?” do you mean looking at the 204 status code and looking at the headers? I guess when the Content-Length is actually present and also 0 then we could take that as another indication of an empty body and return the default.

Although I proposed the Content-Type header earlier I’m actually not exactly clear on what should be done when it is set to something other than json. I think if this header is to be interpreted it will probably need to be done with a responseSerializer config option similar to the proposed bodySerializer. That is probably overkill though, and wouldn’t address the empty body issue in particular.

I’m happy to do the 204 and Content-Length implementation.

marnusw on May 12, 2018

Yes. The fix that was merged for this checks for a 204 status or a Content-Length: 0 header and returns an empty object.

If you have a 200 empty response without a Content-Length header it will not work since the body is not parsed for this check.

marnusw on Dec 11, 2018

@isopterix If the server sets the Content-Length to zero properly it should be working even on 200 responses, the intent is to check for that as well.

marnusw on May 25, 2018