I think you're missing the point that some people prefer reading code over documentation. If your code is literate and uses common conventions and doesn't surprise the maintainer isn't that a good thing? I recall someone showing me an "infinite" loop in the linux kernel. He was surprised. So if you're going to do something surprising, then document it next to the code. 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
