Am I correct in thinking there is no way to customize the HTTP response from the Pulse web service when running web service scripts?
If that assumption is correct, it would be great if the web service script system was updated to allow the scripts to return a meaningful object or piece of data that would be used to build the HTTP response. Right now, the response from every web service script request is just 200, which is often misleading, and which requires ridiculous workarounds to detect errors in web service scripts.
I think the HTTP session response code refers to successful communication (or not) between the client and server, rather than the service response to the message or query being carried over HTTP. It’s a protocol status code not a service status code. So, if a query is successfully conveyed, the proper response is 200 even if the query itself is erroneous with respect to the service. In this example, errors in the query would need to be relayed within the response body.
I have to disagree with you. Doesn’t the fact that you receive a fully-formed response at all imply successful communication between the client and the server?
The general definition I see for a 200 response is, “The request has succeeded.” There’s obviously room for interpretation there, and I know all of the examples shipped with Deadline are just serving information as an HTML page, but I think it’s worth keeping in mind that the web script system allows one to essentially build an alternative REST API for Deadline.
For instance, I use web service scripts to do things like change some job properties on the fly in response to internal studio events, because it’s much simpler and lower overhead than shelling out to deadlinecommand. To me, my script raising an exception maps pretty cleanly to a 500 response code:
If an exception is raised in a web service script, the server has encountered an error, and is definitely aware of it.
Another example: since there are no web service access controls in Deadline, I do my own user group checking. If someone is “not authorized” to do what they’re trying to do, a 401 response would make a lot of sense.
Basically, not being able to control response codes or headers is painful. Providing the web script system has given users plenty of rope with which to hang themselves, so I don’t think taking the response part off the table is much of an advantage to the end user. Right now I’m looking at having to embed what is essentially a second, fully-formed HTTP response in the body of the generic “success” response, and then parse it on the client side to determine what actually happened.
We could add an option to have the main function return a tuple, with the second value being the status code. We could also do it in a way that doesn’t break backward compatibility.
For example, ‘return response’ would work like it currently does, where ‘response’ is the message and the status code is 200. But then you could do ‘return response, 401’ to set the status code to 401.
We can also start returning 500 for any script errors.
All this should be possible for 7.1. How does that sound?
I like the sound of that as a compromise. Do you think there could be a way to return custom headers as well? I thought of maybe returning a 3-tuple instead, in the form (body, statusCode, headers), with the last one being an optional dict, but None by default. It would require some extra validation on your end though.
There are issues with Dictionary handling between Python and .NET, but I think what we can do is allow an arbitrary number of “key=value” strings after the status code which are treated as additional headers. For example:
OK, that sounds like a decent compromise. However, can I suggest supporting the return of an iterable of strings instead of just an arbitrary number of extra items? That way, a list of return headers could be built up by the script and returned more easily and cleanly.
Unfortunately, that won’t work, because our workaround is to treat the object returned by the main function as a list of strings. I know that we’ve been showing the status code in the examples as an integer, but under the hood it’s converted to a string (so returning “200” works the same as returning 200).
What you could do is build up your headers as a tuple of strings, and then insert the response and the status code at the beginning and just return that tuple.
I know it’s all a bit of a hack, but it’s kind of necessary to maintain backwards compatibility (and to squeeze this into 7.1).