Remote APIs unusable in robust solution - check HTTP codes

Remote APIs unusable in robust solution - check HTTP codes

Hi,

I'm the technical lead at huddle.net, an online collaboration system, where we've just put the finishing touches on to our Zoho integration. Overall, my experience has been good, but it is clear that we can't build a robust solution on top of your API.

We currently have two serious issues with the way that the Zoho APIs are implemented.

Firstly, the remote API is broken.

The documentation clearly states that you can return an HTML fragment with output=editor, and that this fragment can be embedded into anb externally hosted page. This is true, but because you're using relative URLs to link external JS, image, and CSS files, the editor doesn't actually *work*. Any time an AJAX request is made, the request is directed to our server, and since we don't HAVE a file called remotesave.do (for example), the request fails. Did nobody think about this during testing?

I contacted your technical support who told me that I should host the editor in an IFrame instead. Since the URIs will still be relative, this would make absolutely ZERO difference to the issue. I suspect that the person in question meant "don't use the externally hosted editor, use URL mode instead".

Our preference would be to use this editor mode as it would allow us to attach our own javascript behaviours to your editor, thereby allowing us to extend the functionality. Example use cases include providing a better loader, giving richer error messages, or disabling the save button when a document is readonly.

If you had at least used a sensible URI structure for the JS/CSS then we could create some kind of proxy to your servers, but the current URI structure does not even allow for this hack. Please use absolute URIs if you intend for HTML to remain valid on an external site.



Secondly, the URL mode editor ignores HTTP response codes.

When we save a document in Zoho, there are a wide number of things that may prevent us from actually saving the document in Huddle.Net. These include: the document being locked by another user, there being insufficient space in the user's account, the document being in a read-only folder, etc etc.

In an ideal world, you would allow us to return a useful error code, perhaps using the same format as you use for sending us the URL, to wit:

WARNING=
RESULT=TRUE

or

WARNING=There is insufficient space to save this document
RESULT=FALSE


I understand why you may be loath to do this (although it would make my life much MUCH easier, and you absolutely SHOULD), but at the very least, you should check the HTTP response code. If I send back a 401 or 500, why on Earth does Zoho continue to say "Document saved successfully"?

I could probably hack up a clever solution using some kind of message queue and AJAX control so that I can report the errors to my users on our side, but we're going to look damned silly if Huddle says "The document failed to save because ..." while Zoho is displaying a message stating "The document saved successfully".

I am unable to understand why you display the success message when you do not receive a 200 OK from the save handler. This is *really basic* network programming.


Please tell me that this is a priority fix. If it isn't, your solution is essentially useless to anybody trying to build decent software. That would be a great shame because the editor itself is a nice bit of DHTML programming, and your MultiPart POST API is a joy to work with.

Yours frustratedly,

-- Bob Gregory
Senior developer @ Huddle.net