New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when REST response is empty #107
Comments
@isopterix -- I don't think we really have an easy way to deal with this right now. -- My initial thought would be to recommend you wrap Fetch & provide a custom Fetch implementation that replaces the body of 204 responses with |
@isopterix I tried to reproduce this issue with the test below, but the test passes for an empty body. It appears that fetch 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 never mind my last comment. It seems the browser implementations are less forgiving than the test environment. |
The one problem that I see with detecting an empty body is that there is no sure way to tell what is in the body without calling Since the rest link produces a
the 204 responses should be the only one to have an empty body. Would it be an option to inspect the status code and return a default @fbartho would you have any preference for one of these approaches? I'll make the PR if one of these options, or a combination thereof, sounds reasonable. |
Perhaps there’s a middle path here? Could both behaviors be supported? I’m pretty supportive of interpreting 204 as {} by default myself, or as “null” is null the semantic equivalent of no content in JSON? |
I think in order for the upstream GraphQL interpretation of the empty body to work we should return
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 Although I proposed the I'm happy to do the 204 and Content-Length implementation. |
So far I followed the earlier advice and implemented a custom fetch to handle the 204 response. But I had difficulty to get a proper response back. Having the option to get this functionality out of the box would be awesome. Unfortunately, I am still learning how to navigate the JS world... |
Fixed via #111 ! |
Sweet! Thank you very much. Now, there is only one little problem still left :) Right after I worked out my own temporary solution, I ran into yet another problem with the REST API of my target SharePoint Server... If you delete an entry you get a 200 response with no body content :) Could we potentially generalize the behavior, i.e. if there is no body content respond with the "NoResponse" tag? If I am not mistaken the patch currently only addresses the 204 special case. |
@isopterix If the server sets the |
Looking forward to give it a spin. |
Does this cover any successful response with empty content? Like a 200 with no content? |
Yes. The fix that was merged for this checks for a 204 status or a If you have a 200 empty response without a |
@isopterix are you able to confirm that this works? I'm trying to do a mutation which gives me a 200 status and |
I see that the response headers are empty when debugging |
Apollo-link-rest does not manipulate response headers @dljcollette! Hope that helps |
I meet same error has any workaround for status 200 with empty body? |
@thomaszdxsn the only way to accommodate that would be to use The best solution would be to change your API so it uses the semantically correct status code 204 when the body is empty, or to return something in the 200 response body. I think even an empty JSON encoded object would work, as long as there is just something in the response body that is valid JSON. If you really can't change the API, perhaps you can pass a custom Or, again, just ensure the API returns the |
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:
The corresponding gql query:
"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.
The text was updated successfully, but these errors were encountered: