API spec and API functionality disparity

[RichardLitt]

I'm going through #13 again, and I'm still a bit confused about what to do if the API spec does not match the API functionality. Often, it may be me now knowing how to work Postman. Sometimes, however, the disparity is caused by a poorly formed API, I think.

For instance, ipfs bitswap unwant should return at 204, not a 200. It doesn't return anything. Should I leave this as a 200, or change it to a 204 and open an issue in go-ipfs?

[daviddias]

From Sprint of January 5th call -> ipfs/team-mgmt#77 (comment)

Let's have the current spec, which describes what is implemented and have the PR's to the current spec with the changes that make sense for each endpoint and open issues in go-ipfs to fix those endpoints

[RichardLitt]

Thanks for posting that here. This can be closed. Current workflow:

• Add in all current functionality, broken or not, in apiary format. This involves drawing from the draft on feature/add and PRing each method into master.
• Get feedback on issues in the PRs into master.
• Merge PRs into master, then PR separate issues where functionality does not match spec (currently undefined), with links to issues on go-ipfs which would enable PRs to be merged.