Endpoint Service: optionally wrap response in json

[cdancy]

Hey All,

So we've got a service here that we plan to potentially make open. The service itself serves upon a response in plain/text and is a single line/string. We had the idea of enhancing the Endpoint Service to check the response, and if it's not json, and if the property wrapWithJson=true is found, then we'll wrap the returned line in the expected json format.

So given the response from the service is HelloWorld we would then return:

{
    "message":"HelloWorld"
}

Thoughts or opinions one way or another?

Thanks,
Chris

[calebcartwright]

My initial reaction is a 👎 but open to hearing more about the use case.

The Endpoint response has the schema that it does because those required fields are required attributes necessary to generate a badge. While it's true that we could pick an arbitrary default color, the absence of a label seems rather problematic as a default, especially considering our badge specification.

This really feels like a case where the Endpoint url should just return the mandatory json response, even if that requires an Endpoint that's acting as a proxy to whatever upstream plain/text target you're referring to (i.e. Shields -> Compliant Custom Endpoint -> Other Thing Which Returns A Single String)

[cdancy]

@calebcartwright fair enough ... but thinking this through maybe I'm going about this the wrong way. I think what I really want is something like an artifactory latest version service. I see you all have loads of these types of services for similar things and feel this might be more in line with what we actually want.

I don't know of a publicly available Artifactory instance as they are usually deployed on-prem or accessible in some cloud behind a wall. If I put a PR together for this (which looking at the docs/code should be simple enough) would you all consider it? This would only be useful for those developers/companies deploying this internally but maybe you all might be OK with that? If you're not OK with that is there a simple enough way that we could write our own module/service and include that at runtime when starting shields locally?

[calebcartwright]

We used to have badges for bintray but we deprecated our badges when JFrog shut down the service.

I'd love to have Artifactory badges because I've got use cases where they'd be personally beneficial. However, as you correctly noted, we're unlikely to find any internet-accessible instances; it's likely exclusively a use case for self-hosted Shields instances, and we've typically steered away from adding any badges that don't make sense/aren't usable in the main Shields.io instance.

I'd suggest as a starting point getting a bit of code together that grabs the data you want from an Artifactory instance, creates the response object that Shields needs, and then use Shields (either https://shields.io or a self-hosted Shields server depending on your needs/interests) to fetch from that custom endpoint.

Gross oversimplification but essentially:

Shields -> Endpoint -> Artifactory Instance

[cdancy]

@calebcartwright sounds good and thanks. I'll throw something together to see how it looks/feels from our end and send our a PR over the next day or so.