The most important paragraph is at the bottom. It depends on the implementation of PUT. If it's implemented as a delete followed by an insert, then it's likely you've lost data like created date, unless you write some clever triggers.
If it's implemented as an update then there's also a chance that you've lost your created date, because a different date could come in from the cliented. Sometimes people really depend on created date and this means hiding it from the client, which means writing one off rest services for all your database tables that have created date. You can also write PUT as a falied insert followed by an update. This often involves writing a special database procedure. You can also do a select before doing all of this, but whoever is coming after you maintaining the code is going to say WTF. Yes I know that some of this can be handled by ORM, then you lose your ability to cache if the data is accesed outside the ORM, perhaps in some reporting framework. 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. The important thing is to make sure your operations are idempotent when they should be...that means with failures as well. I think if you're using POSTs not according to the REST HTTP spec you're asking for all kinds of trouble. As far as I can tell, they should only be used to add items to collections. On Feb 15, 2013 3:13 AM, "David Barbour" <[email protected]> wrote: > > On Fri, Feb 15, 2013 at 12:10 AM, John Carlson <[email protected]> wrote: > >> The way I read rest over http post (wikipedia) is that you either create >> a new entry in a collection uri, or you create a new entry in the element >> uri, which becomes a collection. >> > There are other options. For example, if you have a URI that represents a > particular subset of records in a table (i.e. perhaps the URI itself > contains a WHERE clause) then you could GET or PUT (or DELETE) just that > subset of records in a sensible and RESTful manner. > > (Alternatively, you can PUT a resource that defines a view, then PUT some > values into the view's results. But this requires code distribution, which > is unpopular for a lot of security reasons.) > > For REST in general, the resource identifier schema can be a lot more > flexible or structured than HTTP's URIs (and aren't necessarily limited to > a few kilobytes). But even HTTP's URIs can be applied creatively. > > I read in rfc2616 quoted on stackoverflow that clients should not pipeline >> non-idempotent methods or non-idempotent sequences of methods. So >> basically that tosses pipelining of posts. Face it, REST over HTTP is slow >> > PUTs are idempotent and can safely be pipelined. It isn't clear to me why > you're using POST as the measure for REST performance. > > (POST is not very RESTful. The content of POST does not represent the > state of any existing resource. It takes discipline to consistently use > POST in a RESTful manner. POST is effectively HTTP's version of RPC, with > all the attendant problems. GET and PUT are both much more closely aligned > with REST.) > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
