On Fri, Feb 15, 2013 at 10:30 AM, John Carlson <[email protected]> wrote:
> The most valuable part of the POST is the database generated ID. I > realize there are other ways to do this--batching the creation of IDs for > example. One needs IDs before doing PUTs and GETs. > I generally favor associating IDs with paths or domain values. It is also possible to use a timestamp, or counters. Though, for most cases I want 'stable' identifiers that can be deterministically regenerated and associated, so use of timestamps and counters are not my preference. I can easily generate unique IDs client-side if the ID is derived from a little client information or a session ID. If I need unforgeable or unguessable identifiers for security reasons, I can leverage cryptographic hashes or signatures (HMAC or PKI). In any case, there are patterns that avoid need for 'creation' of identifiers via POST or other means. Many of these patterns have existed for a long time, e.g. in more common use back when the filesystem was a primary persistent state resource. (Creation of 'new' filenames is rarely useful, though some claim dubious utility for temp files.) > Yes I understand the value of obfuscating IDs for security reasons. I > don't really agree with showing any IDs to the user. > There is a difference between "showing IDs to the human user" and "exposing IDs to the client application". To which of these are you objecting? > The rpc operations you list below seem like good reasons for using post. > I would not say they're reasons for using POST. There are more RESTful, idempotent approaches to control printers and similar, such as PUTting a task into a scheduler or tuple space. > Don't assume people read your documentation. And don't blame them if they > don't. Some people have reading disabilities. You should feel lucky if > you have your full capabilities. > The people who need to read documentation about how a system works are the people who maintain, extend, or integrate with it. If they're unwilling or unable to do so, they shouldn't have the job in the first place. > If you expose your created date as a key, then people might be apt to put > collections with their own created dates. You need to test for realism. > I don't know enough about your particular application to say how I'd approach creation dates in your case. Without creation of IDs, I don't often see a use for 'created date', but there is some utility for a 'modified date'. As I mentioned above, timestamps are not to my preference for stability reasons. Though they're okay if they're a meaningful part of the domain values, like a calendar or time-series data. If I feared people would use distant past or future creation dates (i.e. if they had some motivation for doing so that could harm me or my product) then I could secure this easily enough and ensure that PUTs for new resources have timestamps accurate to within a few hours of the server's clock.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
