`ipfs.dag` API docs missmatch implementation.

[Gozala]

So I have implemented ipfs.dag API as per documentation. E.g. ipfs.dag.get per docs take CID instance.

However following tests exercise string and buffer inputs instead:

js-ipfs/packages/ipfs/test/core/dag.spec.js

Lines 22 to 32 in 5e0a18a

	it('should throw error for invalid string CID input', () => {
	return expect(ipfs.dag.get('INVALID CID'))
	.to.eventually.be.rejected()
	.and.to.have.property('code').that.equals('ERR_INVALID_CID')
	})
	it('should throw error for invalid buffer CID input', () => {
	return expect(ipfs.dag.get(Buffer.from('INVALID CID')))
	.to.eventually.be.rejected()
	.and.to.have.property('code').that.equals('ERR_INVALID_CID')
	})

We should update either docs or an implementation. I have also looked at /api/v0/dag/get but I am afraid it did not help me clarify here.

---

I am personally biased towards doing what API docs say, because otherwise in the shared worker use case we end up with double normalization / validation more specifically it would imply that:

1. Client needs to assess cid argument as either string, buffer, or CID.
2. Server piece would need to asses received cid input and decode it to one of those representations.
3. Server will pass decoded args to ipfs.dag.get which in turn will again asses cid argument.

It is also worth noting that if variadic cid is desired, it would make a lot more sense to analyze it in the main thread and error without messaging worker.

[achingbrain]

This is because the API previously specified strings, buffers and CIDs as arguments. Going forward we only want to take CIDs, but the implementation still supports strings and buffers to avoid breaking existing code, though there needs to be a time limit on this.

New implementations of the core API can just support CIDs as per the API docs and skip the interface tests that test with non-CIDs.

[Gozala]

Cool, thanks for clarifying