Hi Joerg,

All points are valid, I have more or less same observations, while
developing Fastox and so far trying to resolve the issues by emailing
developers ;)

Will write a summary after we move Fastox into a better state of
integration.

Best regards,
Nina

Joerg Wicker wrote:
> Hi everyone, 
>
> I am currently working on a Workflow Management System based interface
> to OpenTox. I had to write some BeanShell scripts to access the OpenTox
> web services. In the end work progresses, but there are some points I
> noticed which I think make it hard for (external) developers to
> implement an interface to OpenTox. 
>
> * Bad or non existing error messages. 
>   In most cases, when I do a mistake and submit a wrong call to a
>   service, the only reply I get is a more or less cryptic number (in
>   most cases 500). Then I know in general that something went wrong,
>   but I do not know if it's my fault, if so what exactly went wrong or
>   if maybe the service itself has some implementation problems. 
>
> * Reliable test cases
>   Also, some reliable test cases would make things easier. Some fixed
>   calls of the services with a given input and a given output so a
>   developer can test her or his implementation. At the moment, I had
>   to get some data, and generate some example calls from the more or
>   less elaborated short examples on the web page. If something goes
>   wrong I have to check my calls, my data and in the worst case the
>   service might have problems with this data or the call and I will
>   not get the solution to the problem. In the end, this is related to
>   the problem with the error messages, as I do not know exactly what the
>   problem is if something goes wrong. 
>
> To summarize, it was easy for me to write something for the TUM
> services, but just because I can access the server and check in the
> logs what is send to the server and what exactly goes wrong. And of
> corse we have some example calls to our services. But our services too
> lack some example test case published somewhere and meaningful error
> messages. Writing interfaces for other services was harder, as I
> cannot really see what is going on. So I was stuck frequently with
> some error which in the end was easy to solve but took me quite some
> time to find.
>
> I did not check all the services, but I did not find services which
> gave me meaningful error messages or provide a complete test case. 
>
> What do you think? Would it make sense to provide some test cases and
> somehow implement some standards for the error messages?
>
> Best regards,
>
> Joerg 
>
>