Skip to content

Supporting bad APIs #150

@wcooley

Description

@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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions