Support .JSON output

[digitalkaoz]

it would be perfect to get the resulting information in a json format to use this service from the CLI.

one can write a svg parser for that, but it would be great if i can do the following:

http://img.shields.io/david/gulpjs/gulp.svg works

http://img.shields.io/david/gulpjs/gulp.json should work, and give me something like that:

{
    "dependencies" : "up-to-date"
}

maybe even with more detailed information:

{
    "dependencies" : "outdated",
    "reason": [
        {"name" : "chalk", "0.3.0 < 0.4.0"}
    ]
}

or maybe simply add an extra http header for that, e.g.

X-Shields-Dependencies=up-to-date

[espadrine]

Is this David-specific? I'm not sure how you would expect all badges to do that, especially considering the fact that each badge gets wildly different information from each vendor.

[espadrine]

That said, what is easy is to provide exactly the data that is written on the badge, including its color.

[digitalkaoz]

maybe you could simply return the data retrieved from the vendor in some json format (dont need to be a similar pattern)

or the simple/quick way would be your easy solution

[espadrine]

For many vendors, we don't simply receive some data; we compute data from multiple files. Sometimes we don't even get that data from files, but from HTTP headers. Many of the files we receive are not JSON. Having to maintain that would be a pretty hefty burden, let alone implement it.
The chance of me merging such a huge modification of /server.js is minuscule.

However, just like we have different badge styles, we could have a new "badge" which is actually JSON. The templates for those badge styles are in /templates/, if you want to try implement it.

[reinink]

This is exactly what I need as well. Over at the @thephpleague we're looking to implement a more custom badge design, and having a JSON version would be awesome. Actually, a JSONP version would be better, to avoid any cross origin request issues.

@espadrine With these templates, is it possible to set a different header than SVG?

[espadrine]

You can set up a different header by using a distinct extension. Much like there is .png, .svg, .gif and .pdf, we can have .json.

[reinink]

Cool. I'm thinking it would be handy to have both .json and .jsonp. With .jsonp, the content-type is just application/javascript. See any issues there?

[reinink]

Just taking this a little further, I propose the .jsonp template look like this:

shields_io_callback({
  name: "Build",
  value: "Passing"
})

Adding the values in:

shields_io_callback({
  name: '{{=it.text[0]}}',
  value: '{{=it.text[0]}}'
})

Ideally, since JSONP normally accepts a callback, it would look something more like this. Although, I have no idea how difficult adding a callback like this is.

http://img.shields.io/travis/thephpleague/plates.jsonp?callback=

{{=it.callback}}({
  name: '{{=it.text[0]}}',
  value: '{{=it.text[0]}}'
})

And with .jsonp in place, it would only make sense to also add .json as well, which is simple:

{
  name: "{{=it.text[0]}}",
  value: "{{=it.text[1]}}"
}

The reason I see JSONP as more valuable than JSON is because JSONP allows sites to consume this data using JavaScript, avoiding any server side code. Consider this example:

$.ajax({
    dataType: 'jsonp',
    jsonpCallback: 'shields_io_callback',
    url: 'http://img.shields.io/travis/thephpleague/plates.jsonp',
    success: function (info) {
        console.log(info.name);
        console.log(info.value);
    }
});

[espadrine]

I disagree with the use of JSONP. I feel like this would be the perfect place to use CORS. I see no reason to restrain access from XHR, so having the following header is probably fine:

Access-Control-Allow-Origin: *

[reinink]

Of course, for some reason I keep thinking you're using GitHub Pages, which doesn't allow you to use CORS. Which clearly makes no sense, since this is a node app.

[espadrine]

The image delivery system is hosted on Heroku, so it should work.

[espadrine]

The PR is closed, but I'd like to let this issue linger on.

I am not sure how to convey the information about this feature on the main page.