NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Hi Paolo, Paolo Mazzetti wrote:
Hi Ethan,I am trying to summarize our respective positions and find a common point of view useful to finalize a discussion paper. These are mine opinions and temptative conclusion. Since I think that these issues concern too much technical details for the mailing-list, I send my thoughts directly to you (and Stefano in cc).
I hope you don't mind, I'm CCing the list because I think a number of others would be interested in these details. Also, the other reason for the list is to archive the discussions and I'd really like to keep all of this conversation in one place.
(Sorry to make any uninterested parties hit the "delete" key more than necessary. If anyone really wants this conversation taken off-list, let us know.)
a) On resources and representation. I agree with your interpretation of what resources and representations are in the WCS domain in the sense that different subsets, interpolation, etc. identify different resources and not simply different representations. This means that the query string parameters are not the set of input parameters for a single processing service resource, but actually parts of different resources identifiers. (Indeed only the parameter FORMAT should be considered affecting the representation and not identifying the resource. In a perfect REST world its content should be provided in the Accept header field.). Our (Stefano's and mine) previous note speaking of 'representation' storage was misleading. In my opinion, what is provided by the possible redirection is not a new resource but a (temporary) URI which is an alias of the original URI for the same resource (a resource can have more than an URI). For example the resource http://someserver.net/coverages/foo?bbox=... is assigned a temporary identifier http://someserver.net/coverages/temp/xyz. Anyway the resource is still retrievable at the original (and authoritative URI). This alias is useful because, for example, in the time range of its validity the retrieving of the resource representation could be faster than the retrieving from the original (canonical) URI.
b) On creation and redirection. Taking into account also the previous interpretation I still prefer the redirection response (302 code). In particular, I think that a GET should not create any resource. RFC 1945 (HTTP/1.0) explicitely stated that "/Of the methods defined by this specification, only POST can create a resource/.". In HTTP/1.1 this statement was suppressed, I suppose, for the introduction of methods other than GET, HEAD and POST but I think that its original meaning (GET and HEAD methods cannot create resources) should remain valid. Moreover I think that 302 responses could be cached and the URI provided used more than one time. The RFC says that "/Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field./" (Upper case as in the original). I interpret it on a weak sense such as "If you are not sure about the validity of the redirection then use the original uri" but if the server knows the redirection validity it can provide it in the header and the client can refer to it.
I think dealing with asynchronous responses requires a flexible view of GET vs POST, creation, and "resource". An asynchronously created resource is, in general, only temporarily available and so doesn't affect the long-term state of the system. Even if the response is stored more permanently it still does not change the state of the system as the stored resource could be requested again with the original URI.
The key point in my thinking then is the intent of the request. The intent is to retrieve a resource and not change the underlying data (or cause any other "side-effects"). So, I think the intent of the request is both "safe" and "idempotent" in which case GET seems appropriate.
Of course, that is for a server determined asynchronous response. When a client makes a "store=true" request, the intent of the request is to create a new (though possibly temporary) resource. [Idempotent but not safe?] So, maybe a POST is more appropriate in this case.
Concerning the other two points that you touched in your last email, these are my opinions:1) delayed/non-stored/pull caseWhat happens if two users make the same request around the same time? Does the server have to do the same processing twice?Yes I think that if two users make the same request than the server has to do the same processing twice. (Obviously a smart server could recognize that the requests are the same and make use of a sort of internal cache, but this is an implementation problem. By the way, it is not easy to recognize that two requests are the same, in particular due to the query string which is made of non-hierarchical parameters. E.g. two requests could only differ for the parameters order.)
And even worse, a small difference in a BBOX value might result in the same resource.
Why would anyone prefer the delayed/non-stored/pull case over delayed/stored/pull?By the client point of view the non-stored use case has the only (really small) advantage of avoiding the redirection. But the server has other advantages (especially in terms of simplicity) and could decide to not support the stored use-case for all or some of its resources.Ah ha. Upon re-reading the "202 Accept" section of the HTTP spec, I realize that there is nothing in the spec that says anything about the results of the accepted processing. The 202 response seems to have been targeted only at requests for processing where knowing it has been completed is all that is important. Not, as I have interpreted it, that processing is done and may have resulted in a new resource (all encoded in the body of the response or the results of a status monitor). I think our interpretation of the 202 response is the root of the difference in some of our responses. Though I still find the 202 response the cleanest mapping to an asynchronous response. Whether the accepted processing results in an externally accessible artifact or not, the 202 response seems to capture what is going on. It is up to the body of the 202 response and any response to the "status monitor" to communicate information about any artifacts of the accepted processing.Yes the 202 specification is very plain. Sending 202 the server informs that the request has been accepted but gives no other information about the processing. It simply avoids to mantain the connection open for long-running processes. It seems to be designed as the minimal basis for allowing asynchronous interaction over HTTP. It can be used as is for a polling approach. A more meaningful semantics is demanded to the body content. This is the reason we should define a (XML?) schema for providing information about processing status/result.
I definitely agree that we need to define some XML schema to provide this information.
Taking into account all the previous points we could consider the following approach for asynchronous operations:a) the Client performs a GET on URI Uresb) If the availability is delayed the server sends a 202 providing a link to a status monitor resource (identified by the URI Ustatus) c) the client observes the status monitor (by polling or with a push approach in the future)d) When the resource is available the status monitor responds: d1) 200 and content if storage is not requiredd2) 302 with redirection to alias URI U2 and expiration information (if storage is required)I think that this approach could be considered really close to what RFC says. Let me know what you think.
That sounds good. Though I think of the status monitor as an extension of the body of the 202 response (which is the XML document mentioned above that we need to define). Perhaps this is part of why I had not thought of using redirects. I see this status monitor XML document as removing the asynchronous response from the realm of the HTTP specification (sort of) and instead moving it into the xlink:href world. So, rather than the status monitor response code redirecting us to the new resource, the body of the status monitor response would indicate the new resource was available and provide a link to the new resource. So, here's my take:
a) client GETs the Ures URI b) if delayed, response 202 code with b1) Location header providing status monitor URI (Ustatus)b2) Body containing XML document with status, estimate of completion, and link to status monitor URI (Ustatus)
c) client GETs the Ustatus URI:c1) if still not available, response code 200 with XML document same as response b2 (maybe without Ustatus link). c2) if available, response code 200 with XML document (similar to response b2?) that indicates the resource is ready and provides a link to the resulting resource.
Some very simple XML possibilities ... For b) <asynchResponse status="processing" completionEstimate="2007-10-24T02:34"> <statusMonitor xlink:href="some URI" /> </asynchResponse> For c1) <asynchResponse status="processing" completionEstimate="2007-10-24T02:34" /> For c2) <asynchResponse status="done"> <generatedResource xlink:href="some URI" /> </asynchResponse>
Best regards, Paolo
Thanks. This is a great discussion. Ethan -- Ethan R. Davis Telephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail: edavis@xxxxxxxx P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ ---------------------------------------------------------------------------
wcsplus archives: