Skip to content

Supporting bad APIs #150

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions