Closed mikafinja closed 6 years ago
All in all, this looks great. I really like the date format and to option to upload images for users. Do we want to keep the email field and / or the Gravatar integration?
I don't really know about the barcode stuff. The spec for v1 doesn't include it, but um, that's not your fault.
Transferring amounts between users would probably be nice (see mete#46).
I'd like to announce the possible amounts to deposit via the API, too (see mete#5).
Barcodes updated to be compatible with mete, amount of calories and sugar for products added, transfers between users, amounts of deposits are read- and setable via api (denominations)
I'm not really decided about whether barcodes should have an id different to their content. But otherwise, this looks really nice.
@nomaster @marudor Any thoughts on this?
Indifferent about Barcods.
just added a new path to get user's details via an associated barcode. It is required to build small checkout devices with a 'payment card' as discussed above.
I would like to keep the attribute bottle_size
(or something like this).
And I would like to have defaults for creating new entities.
And if the typo could be corrected, I'm for merging this.
I'm all for merging now.
Could we make the support for uploading user avatars optional (eg. make the server just return an error message or something like that)?
This would help in implementing this API version in mete, because uploading images could be done later™.
(Clients wishing to support older API versions will have to make this optional, either way.)
How about we treat /image as optional (No Idea how to show that in swagge actually) and add a capabilities to /info.json. If we return something like capabilities: { image: true } server supports /image. Otherwise not.
/images is optional. You can query the server if images are supported or not ny sending a get request to /images and it'll return 204 if the server is capable and 501 if the feature isn't implemented (yet).
spec for api version 3.0.0