| > because we are phasing out some old APIs we don't want people to use I still don't see how having API spec with a big fat "everything will break tomorrow, look completely different and may eat your pet hamster - you have been warned" disclaimer is an issue. Existence of a specification doesn't mean that things will be supported forever and are not subject for changes. What matters is that feeling that there's a spec and willingness to publish it - so when it'll be necessary it most likely will be there. If you even plan deprecations ahead and not just refactor things as development goes then I really don't see what could be wrong, because if that's the case - I believe you're better than a lot of in-house APIs I've seen. And if you wouldn't have mentioned that you provide spec on request I wouldn't have thought you have it, and if go with RE. The difference I see is that with open development is so I can persuade myself that when necessity arises I can be sure, having a proper paid account, I can take whatever docs and code is available and help myself. Even though it's recognizably hard it still gives a feeling of safety and control (which IMHO really matters for personal email) - not having to wait for company to eventually possibly release something that may or may not exactly do what I want to have.
Developers are, hopefully, sane enough to understand that if there's a warning that things are under development and change then it means that their code will break. And non-developers won't see the difference anyway. > release access to them Access is completely different from source code availability, isn't it? Your APIs do account plan checks anyway, don't they? |
Re: API access control, sure they do, but given that export is essentially calling 'GET message X' it's not as if we can restrict that to a subset of users.