sugarondrupal.drtsg.net

As I'm refactoring the main part of the SugaronDrupal module, I need to test how reliable the REST (SugarCRM WebServices V2) interface is. As I have already commented, I've joined the SugarCRM testFest to do exhaustive Web Services testing. Although TestFest has not started yet, I've already been testing on my own, in an attempt to get some advantage to the little timewindow available for testing and fixing before the 5.5 version gets released. The following content are the results of my own tests.

I've decided to use simpletest framework, so we can reuse again all the work done once the Beta2 gets released. But due to the lack of documentation (correction: updated documentation) (notice: it's beta1 release, should don't mind about that) I had to guess what are the expected results.

I've developed a test file and ran through the REST implementation of this sugarCRM version, performing the following actions:

- Valid login: a login API call using valid credentials of the admin user.
- Invalid login: a login API call using wrong password for the admin user.

These two cases (valid and invalid) were tested for each one of the following request input and output types:

• JSON >> JSON
• serialize >> serialize
• JSON >> serialize
• serialize >> JSON
• JSON >>
• serialize >>

Also, I´ve included a test to check if name_value_list parameter is working in the login API call.

Despite the number of errors, most of them are just a guess of what the result should be, so they are not important. What is important is that these tests help me to identify the following issues:

• A JSON (input and response) valid login works fine.
• An invalid login operation using JSON as input_type and response_type returns the string NULL, what is not useful at all, as the expected reply should be the error 10: "Invalid login", also, the reply should be encoded in JSON as specified in response_type.
• "serialize" as input_type is not working at all. serialize is only working right when specified as response_type. Any of the tests using serialize as input type generate errors or returns unexpected data: for example: "N;" or a lot of warnings about missing arguments for the requested method.
• A SERIALIZE (input and response) valid login returns the same as the invalid login: the string "N;". No one of them work.

For mixed requests (using json and serialize for input and output)..

• A valid login using json as input and serialize as output works fine!!.
• An invalid login using json as input and serialize as output returns the string "N;" what is not expected..
• A valid login using serialize as input and json as output returns the string "null".
• An invalid login using serialize as input and json as output returns the string "null".
• A valid login using json as input and not sending "response_type" works, but returns a dump of an ARRAY as content :?? . It was expected to return json content?
• An invalid login using json as input and not sending "response_type" also works, but returns html content, with server status included. This is the returned string: "500 Internal Server Error 10: Invalid LoginLogin attempt failed please check the username and password". This is not json, serialized or nothing structured. It's just HTMl content, and unless by trial and error, there's no way to know what the error was.
• A valid AND invalid login using serialize as input type, and not sending "response_type" return a bunch of PHP warnings, about missing arguments. Also returns the string: "500 Internal Server Error 10: Invalid LoginLogin attempt failed please check the username and password". Remember that when response_type is specified as "serialize", NO WARNING is shown about missing arguments.
• Finally, the name_value_list is not working (I guess..) because I tried to set the language to "en_en", but the login operation still returns "en_us". I'm not sure what is expected to be returned, what are the values available for the 'language' value, and if an error should be returned when the arguments are not ok. All this information is missing in the current documentation.

Included you will find the test results in html format, where you could follow what was tested, and which was the answer. Remember again, this is for 5.5.Beta1. Also, it is important to consider that PHP json implementation may lead to errors in json encoding or decoding operations, but this is another history I hope we should not talk about never again..