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. Yes I understand the value of obfuscating IDs for security reasons. I don't really agree with showing any IDs to the user.
I will take your words of advice and try to avoid non-idempotent operations. Seems like a good thing. The rpc operations you list below seem like good reasons for using post. 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. 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. On Feb 15, 2013 4:29 AM, "David Barbour" <[email protected]> wrote: > On Fri, Feb 15, 2013 at 1:52 AM, John Carlson <[email protected]> wrote: > >> I believe the best thing to do is use POST to create objects and quit >> trying to fool people with your smartness. You're only asking for trouble >> if you do otherwise. >> > Ah, the "people are too dumb to understand anything but tradition" > argument. > > I think the concept of 'creation' is not a very good one, not least > because it isn't idempotent. I have patterns and idioms to make do without > it. > > >> means writing one off rest services for all your database tables that >> have created date. > > > If you do such a thing for three or more tables, you should start > developing a reusable abstraction! If I needed to preserve created date or > other metadata, I'd consider modeling it as part of the key. > >> As far as I can tell, [POSTS] should only be used to add items to >> collections. >> > Sure, but that can mean anything at all. Adding procedure activation > records to a stack, or print requests to a queue, are examples of adding > items to collections. POST is equivalent to RPC, even if you phrase it as > adding items to collections. > > >> The important thing is to make sure your operations are idempotent when >> they should be...that means with failures as well. > > > There are many other important things, such as clearly documenting for > your clients and intermediate services which of your operations are safe, > idempotent, cacheable, etc.. The reason REST does well in-the-large > (extensibility, integration, disruption, scalability, etc.) is because of > the clear, end-to-end understandings about the properties of operations. If > you use POST, even in an idempotent manner, you lose a lot of value > in-the-large. > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
