[p3t] Supporting protocol migrations in standards

[Dave Morris]

Hiya,

I agree with the layered approach using profiles to decouple the 
Internet protocol and encoding representation (the
"profile") of a protocol from the specification of the semantics of the 
protocol (the "protocol").

However, I'm still concerned that the term 'JSON-based protocol' may be 
making the same mistake we made 20 years ago when we fixed on XML as the 
standard format.

On 2024-04-18 00:04, Russ Allbery via p3t wrote:
> The new JSON-based protocol we've discussed so far ...

Why have a separate 'JSON' service?

Why not use the HTTP Accept and Content-Type headers to define services 
that can handle more than one input and output format ?

OpenAPI has good support for both the Accept and Content-Type headers.

I have been experimenting with Java Spring for the ExecutionPlanner and 
I have an test service that can both consume and produce XML, JSON and 
YAML without requiring any custom code. The service framework handles 
all of the serialization and de-serialization automagically.

If we pick at least two formats (JSON and YAML would get my vote) and 
require our services to implement both, then it encourages our 
developers to think in terms of class objects and data models rather 
than a 'JSON-based protocol'.

This would help to decouple the encoding representation from the 
specification of the semantics.

-- Dave

ps. Your email uses the word JSON the same number of times as REST and 
HTTP (REST 10, JSON 11, HTTP 14)

--------
Dave Morris
Research Software Engineer
UK SKA Regional Centre
Department of Physics and Astronomy
University of Manchester
--------
AIMetrics: []
--------