apinf / meteor-api-umbrella

Meteor wrapper for the API Umbrella Admin API.
MIT License
5 stars 1 forks source link

Redesign package API to support object instance #3

Closed brylie closed 8 years ago

brylie commented 8 years ago

Currently, the package instantiates an object with configuration variables on load time. This is not ideal, as it does not allow control over load sequence in projects that use the package. Redesign the API so that it is object oriented, and perhaps less nested.

Current project organization

The package currently contains nested objects in the form of:

This leads to a lot of typing, and may prevent refactored code from using attributes assigned to the top level apiUmbrellaWeb object (including baseUrl, apiKey, etc).

Ideas for reorganization

Flat object

One option for reorganization would put all attributes and methods in the top level object:

It might also be possible to have a unified method for each API endpoint, for example:

apiBackends = function (apiVersion, method, input) {
    // Check API Version and select URL prefix based on version
    // Check method for types such as GET, POST, etc..
    // Depending on the method type, the input will catch relevant paramaters, 
      //  such as API ID, or an API Backend object
    // Get the response object, process errors
    // Return the response object
};

Thus, the ApiUmbrellaWeb object would be constructed as such:

I have redesigned the package to use closures, based on an example on Stack Overflow. The re-design follows the original structure, using nested objects. A next step might be to refactor to the unified methods approach.

brylie commented 8 years ago

@mauriciovieira, what are your thoughts on this re-design? What other ways can this package be organized? Are there any good examples I can draw from?