On Fri, Feb 15, 2013 at 1:52 AM, John Carlson <yottz...@gmail.com> 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 fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
