Naming Conventions

This page procedurally documents the naming conventions for methods, objects, and parameters in this package. Refer to this section if you are having difficulty finding a particular service or method corresponding to an HTTP endpoint, though that will hopefully rarely be the case. This section will commonly reference camelCase, CapWords, and snake_case naming schemes.

  • EveryAction Objects are usually named to exactly match a corresponding object referenced in the EveryAction documentation, but with the CapWords convention if that was not already the case (though it usually is). When in doubt, check the documentation for the kwargs parameter of the method you want to call to check the type of object for the JSON data for that method, and the documented return values of a method to determine the type of the returned value.

  • Service Classes usually have names that match the corresponding groups in the EveryAction documentation but with spaces removed, resulting in a CapWords convention. There are some exceptions: for example, the service Email in the EveryAction documentation is called EmailMessages in this package since “Email” conflicts with an Email object .Email.

  • Instance attributes corresponding to services in EAClient usually have names which are snake_cased versions of the service they are an instance of. There are some exceptions for brevity: ReportedDemographics is shortened to demographics for example.

  • Path parameters are positional only and thus their names are irrelevant from the user’s perspective. In this package’s documentation, they are named the snake_cased version of the camelCased parameter that appears in the EveryAction documentation.

  • Query Arguments and JSON data keys have multiple names, but their original camelCased name as given in the EveryAction documentation is always acceptable. However, users may find it more convenient to use their shortened and snake_cased aliases.

  • All methods follow the snake_case conventions. Additional conventions are followed according to what the method does, as described below.

  • Methods which retrieve a specific piece of data that corresponds to the type of data for which the enclosing service the method is named, such as for GET /people/{vanId} (since it gets a Person under the service People), are called get as in People.get().

  • Methods which retrieve a specific piece of data which does not correspond to the type of data for which the enclosing service is named, such as for GET /people/{vanId}/membership are named according to the type of data being retrieved, in this case “membership” as in People.membership().

  • Methods which retrieve multiple pieces of data that correspond to the type of data for which the enclosing service is named, such as for GET /activistCodes, are called list as in ActivistCodes.list().

  • Methods which retrieve multiple pieces of data that do not correspond to the type of data for which the enclosing service is named, such as for GET /people/{vanId}/activistCodes, are named according to the pluralized version of the data being retrieved, such as activist_codes as in People.activist_codes().

  • Methods which create new data, such as for POST /codes, are called create as in Codes.create().

  • Methods which update a specific piece of data, such as for POST /people/{vanId}, are called update when the data being updated corresponds to the type of data for which the enclosing service is named (as in People.update()), and update_X where X is the type of data being updated when it does not correspond to the enclosing service (as in VoterRegistrationBatches.update_status()).

  • Methods which delete a piece of data, such as for DELETE /codes/{codeId}, are called delete when the data being deleted corresponds to the type of data for which the enclosing service is named (as in Codes.delete()), and delete_X where X is the type of data being deleted when it does not correspond to the enclosing service (as in Contributions.delete_attribution()).

  • Methods which modify an existing piece of data by adding a property to it, such as for POST /people/{vanId}/codes, are named add_X (as in People.add_code()), where X is the type of data being added. When such a method may add multiple pieces of data, such as for POST /people/{vanId}/canvassResponses, the name is pluralized as in People.add_canvass_responses().

  • Methods which modify an existing piece of data by removing a property from it, such as for DELETE /people/{vanId}/codes/{codeId}, are named remove_X (as in People.remove_code()), where X is the type of data being removed. No methods of this kind currently remove multiple pieces of data, though in principle the name would then be pluralized.

  • Methods which modify an existing piece of data by setting a property to a value, such as for POST /people/{vanId}/disclosureFieldValues, are called set_X (as in People.set_disclosure_fields()), where X is the type of data being set. All methods of this type currently operate on multiple pieces of data and are thus pluralized.

  • Except for cases previously described, methods which perform an action for multiple pieces of data, such as for POST /codes/batch to create multiple codes, are name X_each (as in Codes.create_each()), where X is the action being performed.

  • Many methods are shortened for brevity when their intent is obvious in the context. For example, to get a particular ballot return status, the method is named return_status instead of ballot_return_status, and other methods under Ballots have similar shortenings.