search

blue-button / blue-button-plus-pull

Spec for BlueButton+ Pull
http://blue-button.github.io/blue-button-plus-pull/
20 stars 11 forks source link

Re-evaluate whether "single provider" endpoint is needed #28

Closed jmandel closed 11 years ago

jmandel commented 11 years ago

Reported by @carloseberhardt via http://wiki.siframework.org/BlueButtonPlus+Pull+API+Documentation+Consensus

Would prefer an example flow that does not require discovery. Seems more complicated than necessary. As a developer, if I need to find the URL to call to make the discovery call, I'm not sure how that's any easier than just finding the API endpoint URLs. What is the benefit, to the developer, of the single-provider discovery call?

jmandel commented 11 years ago

Is the main issue that the app has to perform discovery at all, or that the app has to perform two steps of discovery:

  1. Learn about the provider (e.g. from a BB+ Registry's providers.json)
  2. Learn about API endpoints (from that provider's own provider.json)

The rationale for separating step 2 was to allow providers to expose their own metadata independent of the trust bundles, so updates to authorization servers etc. could be transparent to the trust bundle. This pattern also allows individual providers to declare endpoints in a consistent way even if they're not listed in a (particular) BB+ Registry.

But I could believe that "updating a provider's endpoints" is a less important use case to optimize for than "simplifying provider discovery." In other words, the two-step process may be an example of forcing too much on app developers, for the convenience of providers. Thoughts, @kwboone @jricher and others?

jmandel commented 11 years ago

Justin: we originally had a one-step process, and then raised the issue of who determines which authorizer is used for a given provider. We agree that this information "belongs to" (is determined by) a provider. But who should host the information is a different question. Questions:

Adrian: a "completeness" criterion was established, saying that as much information available for sharing as possible could be managed via BB+. So, would strongly support the solution that would allow providers to use BB+ as the only way to share information at a future date.

Justin: For BB+, the "central entity" in a BB+ network becomes a registry system, as the entry-point to the protocol stack. So a central question is: "would we prefer to have providers manage this information through the registry itself -- which is the central entity of BB+?"

Adrian: My concern is that providers may have additional data (streaming; images; etc) and we want to enable future use cases of random access, new data types, etc.