The last "they" should be "POSTs". Forgive my typos. For some unknown reason I am using my phone On Feb 15, 2013 3:52 AM, "John Carlson" <yottz...@gmail.com> wrote:
> 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" <dmbarb...@gmail.com> wrote: > >> >> On Fri, Feb 15, 2013 at 12:10 AM, John Carlson <yottz...@gmail.com>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 >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >>
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
