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
