Sounds good to me.
On 10 Feb 2015, at 1:59 pm, Barry Warsaw <barry@list.org> wrote:
On Feb 06, 2015, at 04:17 PM, Andrew Stuart wrote:
Yes it’s a tough question. I agree with leaving the uid records in the database to prevent reuse. You are correct my test code is exercising a full working system. It would be good if my tests could leave the database in the same state after completion of each test.
The ideal would be a method that is exactly the same as the existing user delete code but also deletes the users uid record.
maybe as you suggest, url route names like: DELETE
<api>/testing/users/{user_identifier}' or DELETE<api>/reserved/users/{user_identifier}’
Thinking about this some more, and remembering that this is an admin interface (i.e. the authenticating proxy would *not* expose this), what about having just <api>/uids which could be used to access and delete uids. You couldn't post/patch to either the collection url (e.g. <api>/uids) or to individual uids (e.g. <api>/uids/7), but you could delete them *only if there is no user object associated with the uid*, otherwise you'd get an error.
This means you'd still have to delete the user and its uid in two operations,
but as this is primarily for testing purposes, the extra overhead should be
acceptable. We could even allow you to DELETE <api>/uids to clear out the
entire table (but again, only if there are no users...?). I put that
restriction in because I wouldn't want a bug in the proxy (or some other REST
API client) to break the whole system, which would definitely be possible if
you accidentally cleared out the uid table.
If it makes it easier to restrict proxy access to some url space, then we could put this under <api>/system or a new <api>/reserved resource.
Personally I’d not bother with exposing or hiding reserved methods based on environment variables or anything else - as you say, it’s an internal API not mean to used by the public so developers should know not to be using reserved or testing methods in their production code. The extra functionality might introduce bugs and needs writing and testing and documenting - not worth it.
Agreed.
Thoughts?
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9