hello henry.
On 2018-04-08 06:49, Henry Andrews wrote:
> I'm generally in favor of registries, but I'm not sold on it for Problem
> Details. It feels a bit like the One True Ontology problem in semantic
> web. The amount of effort needed to standardize is substantial,
> particularly when dealing with extension fields which may carry fairly
> specific information. I'd certainly be interested if someone got
> something off the ground, but as you know I'm familiar with the
> challenges of getting consensus, or just majority support, from even a
> small community regarding internet standards. I cannot imagine trying
> to solve the error design challenges specific to my API while at the
> same time trying to build support for standardizing the error types.
i think i agree on all of this. but to me, there is a crucial difference
between the "one true ontology" problem and the way it usually is
approached with registries. registries typically work with open
namespaces, i.e. people are still free to make up their specific models.
but if some community feels like something is worth getting
standardized, then they can do that, get it registered, and thus make it
discoverable.
it very well may be that such a registry would remain small. how much
people invest in standards usually is a direct function of the utility
of standardization. so if there is infrastructure and tooling in place
that does useful things with standardized values, then you might see
people investing in standardized values. if it's just the theoretical
exercise of "let's standardize because of yet unknown potential value in
the future", probably not as much.
this means that the landscape architects in API orgs are the ones that
influence the dynamics: if they support/build tooling/infrastructure
that does useful things in a more coherent landscape, things will evolve
in this way. if there is no incentive or value beyond standardization
for the sake of standardization, there will be little natural momentum.
to me, the best path to take is:
- make sure to allow paths of standardization.
- influence incentives by providing tooling/infrstaructure for the
things where standardization can create value.
- support standardization through platforms such as registries for those
cases where it provides value.
> I consider API-specific error RFC 7807 "type" URIs to identify resources
> in much the same way that the "normal" API resource URIs do. And of
> course RFC 7807 "instance" URIs are actual accessible resources within
> the API.
> I'd love for my resources, error or otherwise, to be broadly
> machine-recognizable, but really the only place where I see the need for
> that to be worth the cost (given current technology maturity levels) is IoT.
we'll see. once again, i agree to all you're saying in principle. but
the mechanics here really are the usual "not invented here" mechanics,
right? sure everybody can go ahead and re-invent that specific part of
their API language. but the economics of that decision are influenced by
how much it costs to reinvent the wheel, and how easy it is to find
wheel parts that work well. and the economics also are influenced by the
value the org can get out of more people using the same wheels.
cheers,
dret.
--
erik wilde | mailto:
erik....@dret.net |
|
http://dret.net/netdret |
|
http://twitter.com/dret |