It the releases API intended to sometimes return a one-line JSON?

[MichaIng]

Select Topic Area

Question

Body

To not depend on tools not guaranteed to be available on Linux distros, we use awk to parse asset URLs and release tags from the API like https://v-api-github-com.adclosenn.dev/repos/MichaIng/DietPi/releases/latest expecting one key: value pair per line.

This worked perfectly reliable until a few months ago, where the API started to return the whole JSON as a single minified line in a few rather rare cases, depending on client location, sometimes changing from request to request. Also, in browser, the same URL always returns the beautified multi-line JSON (without enabling browser-wise beautification), while e.g. curl remains returning it in a single line. I have the impression that a few edge servers might do minification depending on user agent.

Is this intended, so that we should switch to a parsing method that works with single-line as well as multi-line output, or does one edge behave not as intended?

[supriopramanik]

treat this as expected behavior.

GitHub’s REST API guarantees valid JSON, not a specific whitespace/line-break format.
Pretty-printed vs minified JSON are semantically identical; edge/CDN behavior can vary representation.
Browser views are often auto-formatted by the browser/devtools, which can make it look consistently multiline.
Even with stable headers (for example Accept + API version), whitespace is still not a contract.
So yes, you should switch away from line-based parsing and use a parser/pattern that works for both single-line and multi-line JSON.

[MichaIng]

Okay, thanks for the quick reply. If anyone else lands here, we found a quite neat PCRE grep, to use if the host OS is known, i.e. it is assured that grep is built with PCRE support (-P flag):

grep -Po '"tag_name": *"\K[^"]+'

Works with any field, and prints each match of every line on an individual output line. Hence this also works on releases instead of releases/latest, e.g. to pass all matches through some sorting, or as overview. Matching only tag_name in all-releases API does not make sense, use https://v-api-github-com.adclosenn.dev/repos/owner/repo/tags instead, but e.g. to find release assets via browser_download_url it can be necessary if patch releases for older major versions are still done.