0

I am trying to consume a JSON API using Flurl

If I use .GetStringAsync() the API returns as follows:

{} && {identifier:'ID', label:'As at 15-11-2018 6:25 PM',items:[...]}

However, when I try .GetJsonAsync<MyObj>() the properties are all null, I assume because of the {} &&.

Is there any way to force Flurl to ignore this and use the actual JSON data, or do I have to use .GetStringAsync(), manually remove the {} && and deserialize?

ADyson
  • 57,178
  • 14
  • 51
  • 63
Shevek
  • 3,869
  • 5
  • 43
  • 63
  • if the API is sending you that, it's not valid JSON. In fact it's not valid JSON anyway even without the `{} &&` bit - there are no double-quotes round the property names, and the values are single-quoted (where they should be double-quoted). I'll assume the `...` is your own change for brevity? Paste the string (the bit after the &&) into https://jsonlint.com/ and you'll see what I mean. A kind de-serialiser might let you off, but you can't guarantee it will get parsed correctly. Seems a strange thing to send back...what API is this?? Is it perhaps a JSONP endpoint or something? – ADyson Nov 15 '18 at 11:23
  • But to answer your question, you can't tell a de-serialiser to de-serialise something which isn't valid JSON, or even close to it, and magically know what to do. It's just parser. It's like expecting the C# compiler to overlook some of your syntax errors. It can't magically know what the intent was. So yeah you'll have to manually remove the really dodgy stuff from the start of the string and then hope it manages to parse the slightly-dodgy stuff in the remainder. But first I'd take a closer look at where you're getting the data from, it's certainly not a conventional REST API response... – ADyson Nov 15 '18 at 11:29
  • yep `...` is me clipping out the bulk of it. It's a trade tape from a financial exchange – Shevek Nov 15 '18 at 11:30
  • Ok. I don't know what a "trade tape" is, I guess that's some finance-speak rather than an IT term? But anyway have they got any documentation about their API which might explain this odd-looking response? Perhaps it would mention if this was intentional, and why, and maybe some explanation of what clients receiving such a response ought to do about it. – ADyson Nov 15 '18 at 11:36
  • Like I said, even if you take off the bit at the start, it's still not proper JSON produced by any valid serialiser, so I don't know what they think they are playing at, if they're claiming it's JSON ...does the response have an "application/json" content-type in the headers? Or something else? – ADyson Nov 15 '18 at 11:38
  • ha, sorry, trade tape is a public list of trades being made on the exchange. Newtonsoft.Json can parse the second part after manually stripping the first bit. We have requested some documentation – Shevek Nov 15 '18 at 12:48
  • I asked the question because it seems to be a standard method of hijack prevention so was wondering if it was built in to handle it – Shevek Nov 15 '18 at 12:49
  • "a standard method of hijack prevention"...have you got a reference for that which I can read please? It's not something I have come across previously. – ADyson Nov 15 '18 at 12:51
  • I did say "seems" - its from my googling having seen the api output. See https://groups.google.com/forum/#!topic/firebug/B1zgO5N6Sus and https://stackoverflow.com/questions/21999572/difference-between-n-and-in-avoiding-json-hijacking – Shevek Nov 15 '18 at 12:56
  • Ah, I have heard of something like that previously, actually, now I look at it. It's only an issue in ancient browsers, it would appear. But it's odd because the particular bit of data they're providing here isn't vulnerable anyway, and never was - only arrays were vulnerable, not objects. So if that's their intention, then it's completely pointless, and besides there are far better ways to solve it and still produce valid JSON (e.g. wrap the array in a single-propertied object), instead of making the caller employ irritating workarounds. – ADyson Nov 15 '18 at 13:03
  • well, the financial markets are a bit archaic :) – Shevek Nov 15 '18 at 13:55

1 Answers1

1

It doesn't look like there is an inbuilt way to do this with Flurl so my workaround is to use Flurl's string method, manipulate the string, then use Newtonsoft to deserialize:

var response = await url.GetStringAsync();

if (!string.IsNullOrEmpty(response))
{
    response = response.Replace("{}&&", "");

    var feed = JsonConvert.DeserializeObject<MyObj>(response);

    ...do stuff...

}
Shevek
  • 3,869
  • 5
  • 43
  • 63
  • 1
    That's definitely the way to do it, and you might consider wrapping this in an extension method if you haven't already. I'm not sure what else Flurl could possibly give you in terms of an "inbuilt way to do this". Consider JSON _is_ a text-based (string) format, and if that string is not _valid_ JSON then it isn't JSON at all. Standards are kind of strict that way. ;) – Todd Menier Nov 18 '18 at 16:58