got: Cannot pass string as json body with json = true option

Versions

got: 8.3.1

Code example

Try to call got with string as json body:

got(url, {
  method: 'POST',
  json: true,
  body: 'str'
});

Expected behavior

No errors. The code above is similar to:

got(url, {
   headers: {
       'content-type': 'applicaiton/json'
   },
   body: JSON.stringify('str')
})

Also I can pass any other primitive types (null, number) which are valid in JSON.

Actual behavior

I got the following error:

 TypeError: The `body` option must be a plain Object or Array when the `form` or `json` option is used

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 21 (9 by maintainers)

Most upvoted comments

An alternative might have been to not make json a Boolean and instead make it the actual JSON body to be used instead

I don’t see how that is ambiguous vs adding to the body property to say it accepts objects, which it does, but only if you read further down to where the json property is mentioned…

Maybe just link to the json property to reference it from the body property and it will probably be enough, I just don’t understand the big defensive stance over the docs. Most developers write inadequate or terrible, assumptive documentation and this is actually quite good. I migrated from request because its bloated, then from axios because it is full of bugs and inconsistent, undocumented behaviour. I’m just trying to suggest a small change to benefit everyone and I really don’t see the supposed detriment to making things clearer but maybe 671 solves it like you said anyway. This did make me laugh though:

Anyway, I don’t mind a note in the README that the body is stringified (though it’s obvious) 😃

Most users running into confusion around this option seem to because of their assumptions

I hope this doesn’t come across as snarky, so happy holidays guys and thanks for the work on this package 🥂

clocked0ne on Dec 28, 2018

@szmarczak the sentence is not grammatically correct, but I’m glad you found beauty in it haha 😄 .

Alright. I remain quite unconvinced. Most users running into confusion around this option seem to because of their assumptions, not because of ambiguous documentation. That’s understandable, but not helpful to try and compensate.

As always, anyone reading along hit by the same issue, please upvote the first comment. Currently, there are zero upvotes which makes me reluctant to change things. Still, I’m in a good mood, let me try to hit some middle ground 😁 .

alextes on Dec 24, 2018

I’m against putting object or list of object as the type for body. That list should not depend on anything. I don’t like the confusion there around the fact it can be but again, json is just for convenience.

I’m not too opposed but still hesitant to the idea of copying the clarification to the body description 🤔. After all, the issue is with the json option, people not using that seem to be fine. Are you sure you think this would help?

We only put things in the documentation that we feel provide value. Doubling warnings, adding emphasis, or increasing fonts, has a cost and should be used sparingly in my opinion. You can pass a JSON string just fine, as long as you’re not also using the json option. If you’re using the json option but not reading what it does, I’m not sure there’s much we can do. In short, are you sure doubling documentation is the helpful approach rather than users reading the documentation in the first place?

alextes on Dec 24, 2018