Re: Structure Fields bis: JSON mapping (#2504)

The discussion so far has convinced me that if we do anything like this, it should be in a separate document, not bis -- there's too much to discuss to fit it in neatly there.

Cheers,


> On 15 Apr 2023, at 7:36 am, David Benjamin <davidben@chromium.org> wrote:
> 
> What sorts of places were you imagining using this? Since the data model doesn't align with JSON, this (and I suspect any) mapping is quite verbose. JSON suggests interchange (it's right there in RFC 8259's abstract!), but I can't see using it in any JSON-based protocol. Just embedding the textual HTTP representation in a JSON string would be more efficient.
> 
> If it's not for interchange, and just for some kind of API, I can't imagine anyone wanting to embed "@type": "string" and "@val" into an API surface. Rather, given the incompatible data models, I think APIs would need to use the host language in non-JSON ways to better capture SF's data model. In that case, a verbose JSON mapping doesn't help. (Had SF's data model been more JSON-compatible, it'd be another story but, for better or worse, that's not where we are.)
> 
> Going through the exercise of designing a clean and simple APIs seems prudent (and perhaps, in an alternate design path, could have informed the data model!), but it's not clear to me how this does that.
> 
> David
> 
> On Thu, Apr 13, 2023 at 9:44 PM Mark Nottingham <mnot@mnot.net> wrote:
> *editor hat*
> 
> Just to make sure people saw it: <https://github.com/httpwg/http-extensions/issues/2504>
> 
> SF's data structures are somewhat weird, because of how HTTP fields work. It might be useful to suggest (not mandate) a mapping to JSON data structures, e.g., in an appendix.
> We talked about what the right mapping should be in the 2022 HTTP Workshop, and this was what we ended up with on the whiteboard:
> 
> ~~~
> {
>    "@type": "string",
>    "@val": "foo",
>    "a": 1,
>    "b": 2
> }
> ~~~
> 
> Note that @type could default to string.
> 
> Thoughts? Is this worth putting into an appendix? Personally, I think it could help drive convergence in APIs for SF -- *if* we're reasonably certain we have the right approach.
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 17 April 2023 02:05:31 UTC