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
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
Topic Participants
bob_gregory
Ahmed Hussain
Sticky Posts
Slicers are now available in Zoho Sheet—filter your data interactively
At Zoho Sheet, we diligently track user requests and feedback. In line with this, based on extensive user requests, we've integrated Slicers to pivot tables and are delighted to announce its release. Slicers are interactive visual filters that have add,Check out the new Checkbox in Zoho Sheet
Checkbox, the simple GUI widget that lets you choose between two mutually exclusive options i.e Yes or No, is now in Zoho Sheet. Having made it across the web, Checkbox is familiar but is still elusive to most spreadsheet software. Special developer ribbons, macros and all other complexities to add a checkbox to a spreadsheet? Not in Zoho Sheet. How to add Checkbox to Zoho Sheet? Adding a Checkbox in Zoho Sheet is simple. Select a cell/range and choose "Checkbox" in "Input Controls" under the FormatFormat and analyze spreadsheet data with Zoho Sheet's Table
While a spreadsheet helps you compile data for easy analysis, formatting helps make your data more comprehensible. We are happy to announce the release of Table, a crucial tool for improving data formatting in Zoho Sheet. More than a formatting tool,Introducing Data Bars: Graphically represent changes in data within the cells
Conditional formatting has helped millions of spreadsheet users analyze and highlight their data more efficiently. In addition to the classic rules, color scales, and icon sets available in Zoho Sheet, you can now apply Data Bars, a convenient methodZia in Zoho Sheet now makes suggestions on conditional formats, picklists, and checkboxes
Zia, Zoho's popular AI assistant, has been helping users succeed across Zoho applications since inception. In Zoho Sheet, Zia helps users efficiently build reports and analyze data with recommendations about data cleaning, charts, and pivot table. Also,