search

hyperledger-archives / aries-framework-go

Hyperledger Aries Framework Go provides packages for building Agent / DIDComm services.
https://wiki.hyperledger.org/display/ARIES/aries-framework-go
Apache License 2.0
238 stars 160 forks source link

Get Credential By ID - Discrepancy between WASM and REST API #1411

Open rolsonquadras opened 4 years ago

rolsonquadras commented 4 years ago

Get Credential By ID - WASM - the id value is passed as it in the request REST - base64 encoded version of the id is passed in the path prarm of the request as the Credential ID is a URL (eg http://faber.edu/credentials/1989) and it messes up with path param of HTTP GET request.

https://github.com/hyperledger/aries-framework-go/blob/master/pkg/controller/rest/verifiable/operation.go#L105

llorllale commented 4 years ago

I think this is by design and should remain as-is. Path params obviously need base64URL encoding, and it would be wrong to have the JS user do this encoding when using one implementation vs another. The JS implementation should do the required encoding (likely ariesREST in this case).

rolsonquadras commented 4 years ago

Yes @llorllale , that was the original thought I had when implementing the REST and Command APIs in PR - https://github.com/hyperledger/aries-framework-go/pull/1348/files#diff-d832b35183deb5aff96d5f3abd5e444eR99-R107. But while writing the BDD tests for JS, I had to change the input based on the mode (rest v wasm).

I remember the earlier discussion of having common JS API (req/resp), so that it would be transparent switch between REST and WASM (just a import change). So the question is whether we still going to match the APIs or allow deviation based on use case? (I missed to add this question in issue description).

@troyronda @sudeshrshetty thoughts ?