I am against showing ids to the end user. With rest you can do a get on a collection uri and see all the entry ids. On Feb 15, 2013 1:33 PM, "David Barbour" <[email protected]> wrote:
> > 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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
