On Thu, Aug 10, 2017 at 12:18 pm, Mark Fletcher wrote:
OK. Our mods wouldn't be used to using that section for notes on members so it should be easy to store some structured data in there for now without much risk.
OK, although just thinking about this a bit more for my particular case I'm not going to have the object ID at the right point depending on how the member is being invited/added. I'm unfamiliar with the direct add functionality at the moment - is it the case that when a user is 'direct add'ed to a group via the web UI, a stub user account is created? If so, with the API, as long as I can get that object ID (or even the full user object) in the response to a 'direct add' API call that could work at least for direct add scenarios (I assume for more traditional invite scenarios the user isn't created until they accept the invite?)
Looks good especially the versioning bit, however I feel it's inaccurate to state that "changing the length or format of object IDs or other opaque strings; this includes adding or removing fixed prefixes" are backwards-compatible. They might be from an API perspective, but if external systems are going to be storing these IDs they mustn't change - ideally at all, but if they must then it should be against a specific API version.
It would be nice if more of the error responses used their related HTTP codes - 401/unauthenticated (the 'real' meaning), 403/unauthorized, 429/rate limit and so on rather than bundling them into a custom error object - avoids deserialising them when a simple HTTP code check would suffice.