UWS 0.4

[Patrick Dowler]

On 2008-6-6 02:22, Paul Harrison wrote:
> I have uploaded a new version (0.4) of the UWS document

I am in the process if implementing a REST UWS framework (pretty 
straightforward so far) and have the following comments about the 0.4 draft:

2.1.1

Second sentence says the job list can be read (GET), presumably by anyone. I 
don't think that is a good idea as I don't think it should be required that 
users can see what others are doing (provider policy issue).

2.1.6

The second sentence should be removed now that POST to phase is the way to do 
this.

2.2.1.3.1

The response when creating a job is a 303 (redirect) to the URI for the job. 
That works fine, but http also provides a 201 (CREATED) which also contains a 
Location header. Maybe cosmetic... maybe browsers don't handle 201 well.

2.2.1.3.2

The response is supposed to be a 303 (redirect) to the job list URI, but given 
the above (job list may not be readable) perhaps a better response to DELETE 
would be 204 (NO CONTENT), which means "yes I did that" and there is no 
response entity (and in the case of a user agent, it does not change document 
view).

2.2.1.3.3 and 2.2.1.3.4

Is that mimetype really supposed to have 4 w(s) instead of 3? 

2.2.1.3.5

The response to changing the phase is a 303 to the (changed) phase resource, 
but http also provides a 202 (ACCEPTED) for the purpose of async operations. 
The response entity should contain an indication of the current status, which 
could still be the Location of the (changed) phase since the phase nominally
expresses the status. As above, maybe cosmetic... maybe browsers don't handle 
202 well.

2.2.1.3.6

"aboted" in the first sentence should be "aborted"

For the above http codes I mentioned, I only looked at the text/meaning in

   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

--
Finally, a suggestion for possible inclusion:

In thinking about using the UWS pattern, it occurs to me that most services 
will probably allow for the specifying of input data. Should there be a 
standard "input" resource (there is a result) with standard semantics? If a 
specific service does not support inputs (due to the specific spec not 
defining them or making them optional), it could just respond with a
403 (FORBIDDEN) or 405 (METHOD NOT ALLOWED).

"input" would be a resource list and could operate like the job list, where 
the caller can POST to the input resource to create a new resource, and gets 
a 303 to the new resource (to find out it's name). With POST, there could be 
a required URI param with the URI (http, vos, etc) to the content. Maybe
PUT should be used for inline content. Presumably the input list would be 
mutable until PHASE=RUN and after that they would not be. 




-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)