On 02/03/2016 11:55 AM, Phillip Hallam-Baker wrote:
> The reason I would like to have consistency across JSON/HTTP type
> services is that we are going to hit a requirement for 'service
> management' type functions at some point. Things like negotiating
> protocol version, features, declaring end of service, transfer to
> another, scheduled outages, that sort of thing.
>
> That is a module that I would hope we could define once and then
> incorporate by reference in many Web Services.
>
>
> The syntax of the request is currently:
>
> {
> "resource": "new-reg",
> "contact": [ "mailto:[email protected]";, ..]
> }
>
> Now that has all the information we want but there is no guarantee
> "resource" is going to be emitted first in the serialization. That
> could be a problem if you are dealing with abuse cases like very long
> messages.
>
> As a structural matter, I prefer to guarantee that the description of
> the object precedes the object. So I prefer to describe 'new-reg'
> object like so:
>
> {
> "new-reg" : {
> "contact": [ "mailto:[email protected]";, ..]
> }
> }
I strongly support this. In implementing Boulder for Let's Encrypt, we
ran into a similar problem with challenge types. Since challenges are
distinguished by a "type" field within the JSON itself, we wind up
representing all challenge types as a single super-type that encompasses
all their fields, and then switching on the string value of the type
field. I'd definitely prefer to be able to keep the different types
separate, which is possible in a system like the one you propose.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
