I know that the meaning of REST has been diluted a lot, but this mostly RPC with pretty URLs.<p>I don't understand why they don't support PUT and DELETE. They are already using jQuery on the HTML implementation of their API site, so could use its Ajax library to provide cross-browser PUT and DELETE. If they wanted browser usable methods, they could have used the standard "_method" parameter along with POST, and convert it server-side.<p>This actually makes it a lot less discoverable for those of us not using the HTML view. For instance, when using curl to browse to /vi/client/list, I expect to get a list of clients. Instead, I get the following (I'd prefer to show JSON here, but I get a 500 when I try it.):<p><pre><code> curl -H "Accept: application/xml" https://api_test:submarine@api.snapbill.com/v1/client/list/
<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="https://api.snapbill.com/" status="ok" type="form"><fields><field type="textbox" name="query"><caption>Search query</caption></field><field type="number" name="page"><class>number</class><default>1</default><caption>Page</caption><min>1</min></field><field type="number" name="perpage"><class>number</class><default>25</default><caption>Clients per page</caption><max>50</max><min>1</min></field></fields></response>
</code></pre>
When I try to GET <a href="https://api_test:submarine@api.snapbill.com/v1/client/list/?number=2" rel="nofollow">https://api_test:submarine@api.snapbill.com/v1/client/list/?...</a>, I get the same response, which I was not expecting. I had to POST to the same URL in order to view the list, which is the wrong method.<p>There's also the issues of assuming a certain view in the end representation, including CSS and JS in their HTML representation, and having different default formats for different resources. All these make working with the API annoying.