Supporting bad APIs

[wcooley]

What features (or plans thereof) does Tapioca have for supporting HTTP+JSON APIs?
I really like what you've put together but I am integrating with vendors whose APIs are not RESTful, although they use HTTP+JSON and are pretty much all CRUD operations.

As a consequence, the simple resource mapping used with tapioca-facebook and others does not work for these APIs.

For example, one vendor's API has separate URIs for every CRUD operation (and several variations for updating different parts of a single resource), in addition to the HTTP methods:

https://www.pebblepad.co.uk/l/resources/documentation/api/Api.Controllers.Version1_1/UserController.htm

Another example, this vendor's API multiplexes resource access through a single .../instances route (sorry about the PDF; only thing available) (see ch4 for API endpoints & ch6 for data classes):

http://partner.lenel.com/file/onguard/7.4/userguides/OpenAccess.pdf

Looking over the code, it seems like I'd need to subclass TapiocaClient and TapiocaClientExecutor, overriding get, post, etc (to simulate usual RESTful semantics) and possibly _get_client_from_name, _wrap_in_topioca* (to produce things using the specialized classes) (although I am hesitant to muck with attributes with a leading underscore).

[filipeximenes]

Hey @wcooley, thanks for reaching! Tapioca was made with REST in mind and there's currently no plans on improving support for non RESTful APIs. I do understand what you are going through and I know that this is the case for many APIs around. I don't know how can we make the changes you need without compromising the features we have. I'm happy to hear your ideas (or review a PR proposal). Otherwise, unfortunately you will need to override some _ attributes 😛