Space-Market / API

MIT License
7 stars 3 forks source link

[F] version 3.0.0 - major changes in api #2

Closed mikafinja closed 6 years ago

mikafinja commented 7 years ago

spec for api version 3.0.0

YtvwlD commented 7 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.

YtvwlD commented 7 years ago

Transferring amounts between users would probably be nice (see mete#46).

YtvwlD commented 7 years ago

I'd like to announce the possible amounts to deposit via the API, too (see mete#5).

mikafinja commented 7 years ago

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)

YtvwlD commented 7 years ago

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?

marudor commented 7 years ago

Indifferent about Barcods.

mikafinja commented 7 years ago

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.

YtvwlD commented 6 years ago

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.

marudor commented 6 years ago

I'm all for merging now.

YtvwlD commented 6 years ago

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.)

marudor commented 6 years ago

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.

mikafinja commented 6 years ago

/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).