The v1.register method should return a VeresOneDidDoc about did-io

[dmitrizagidulin]

@gannan08 are you sure? The thing about register() is that it requires an already generated DID Doc to be passed in. What would be the point of returning it? (It's immutable.)
The reason it's returning an axios response is so that the calling code can judge success/failure.

[mattcollier]

@dmitrizagidulin there were some test written against this API that were working before largely based on this documentation: https://github.com/digitalbazaar/did-io#generating-and-registering-a-veres-one-did-document

Perhaps returning the did document is optional, but throwing an error on failure is a requirement. Discerning a failure condition based on axios response is did-io's job IMO.

[dmitrizagidulin]

Discerning a failure condition based on axios response is did-io's job IMO.

Sure, agreed. I was thinking more about app-level logic failures (like, the ledger saying "your accelerator proof didn't check out"), which are less the domain of axios? Or are you thinking like, those kind of errors should return as status 400 anyways, in which case axios will throw em? In which case, yeah.

there were some test written against this API that were working before

Wait, did the tests break now, or..?

[mattcollier]

The test in question was patched earlier today, it passes like this: veres-one/veres-one@3a69c04

We would like it to be restored to it's former self.

[mattcollier]

We're talking about the register API. :)

[dmitrizagidulin]

We would like it to be restored to it's former self.

Ok. So you'd like register() to return the did doc, makes sense.

Do you foresee any need for the register call results from the ledger?

We're talking about the register API.

Riiight, ok, I was meta-confused :)

[mattcollier]

If the concern is that we might need to float axios errors up the stack, maybe something along these lines is appropriate? https://github.com/digitalbazaar/http-signature-header/blob/master/lib/HttpSignatureError.js

So, I would think that if the HTTP API returns some json schema validation error (for instance), the caller of did-io would need to have access to that information to address the cause of the failure.

[dmitrizagidulin]

@mattcollier So the errors I could see - they'll propagate like exceptions usually do.
What about successes? Do you foresee any need for the success results?

[mattcollier]

Are there different flavors of success? Are we speaking about the register API specifically or did-io APIs generally?

[dmitrizagidulin]

I don't know, re different flavors of success. :) (And yeah, talking specifically about the register API).

Tell you what, I'm cool with just having it return a did doc, and discarding the register results, for now. If we need em later, we can refactor.

[gannan08]

To understand this correctly if the server returns a 204 (Success) we will be returning a did doc, else throw an error?

[dmitrizagidulin]

To understand this correctly if the server returns a 204 (Success) we will be returning a did doc, else throw an error?

Right!

[dmitrizagidulin]

Merged, closing.