JSON API content type
williamn opened this issue · comments
Hi,
I am using Wuzz to test my JSON API endpoint. The problem is Wuzz doesn't format the response body. From the code I see that Wuzz only format if the config is true and Content-Type is application/json while JSON API require the server endpoint return the Content-Type as application/vnd.api+json.
Do you have suggestion to solved this?
You've done a great work with Wuzz.
Thank you.
Perhaps we should be using https://golang.org/pkg/mime/#ParseMediaType to parse the Content-Type header?
@nwidger yap, definitely that would be the proper solution.
@asciimoo I'll try and send a PR for that in a few.
@nwidger awesome! thank you.
I have tried the new code, I just find out that my endpoint return Content-Type: application/vnd.api+json; charset=utf-8 and wuzz failed to recognize it as JSON. Perhaps because of the charset? What do you think?
@williamn I'm pretty sure mime.ParseMediaType handles parameters correctly. Here's a Playground link showing it's behavior with application/vnd.api+json; charset=utf-8:
https://play.golang.org/p/F1H0FnDFgg
Are you sure the formatJSON config option is enabled and that the JSON body being returned is properly formatted? Either of those would prevent wuzz from colorizing a JSON response despite successfully detecting it as JSON from the Content-Type.
@nwidger yes, I got formatJSON = true in my ~/.wuzz/config.toml and my JSON response is valid. Is there any other way to test?
@williamn Is there a wuzz incantation for a public API endpoint that you can provide that exhibits the bad behavior you're seeing?
@nwidger I create a mock of my endpoint here http://www.mocky.io/v2/58b404b3110000c7191c4371
@williamn this works well for me. wuzz http://www.mocky.io/v2/58b404b3110000c7191c4371 displays the highlighted and formatted json.
Strange...
Here is my output of running wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371 (default config):
@asciimoo I tried to use wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371 but in my side the result is the same 😁
@williamn what is your go version? i'm using go version go1.8 linux/amd64
@williamn Perhaps try building in a fresh GOPATH to rule out any stale dependencies?
mkdir ~/gotmp
GOPATH=$(realpath ~/gotmp) go get -u github.com/asciimoo/wuzz
~/gotmp/bin/wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371
@williamn If that worked then it could be a couple of things:
What does which wuzz return? If it doesn't return $GOPATH/bin/wuzz, then you've been running some other wuzz binary from an entry in your PATH environment variable. You should either delete those versions of wuzz or reorder PATH such that $GOPATH/bin is searched sooner.
It's also possible you have been running $GOPATH/bin/wuzz this entire time and simply have out of date versions of wuzz or some of its dependencies. The simplest thing would probably be to run:
rm -rf $GOPATH/src/github.com/asciimoo/wuzz
go get -u github.com/asciimoo/wuzzand then see if $GOPATH/bin/wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371 works correctly.