Data Type Selection for Distributed APIs
- Updated2023-02-17
- 2 minute(s) read
Data Type Selection for Distributed APIs
Refer to the following table for best practices for selecting data types.
| Guideline | Required or Recommended? | Details | Example(s) |
|---|---|---|---|
|
For numeric input or output values, use double-precision for floating-point values and I32 for integer values unless there is a specific reason to use another type. |
Required |
N/A | N/A |
|
Always use an error cluster for reporting error conditions. Never use an error code or error Boolean output by itself. |
Required |
G Web Development Software has a single Error API for error handling. If API VIs do not use the error cluster to convey error information, you cannot use the Error API for handling errors. | N/A |
|
Use a text ring only for parameters that have a natural association to several discrete possibilities and no numeric content. |
Recommended |
An exception for numeric content is if the set of valid values is sufficiently small. |
Examples of discrete possibilities without numeric content are days of the week, months of the year, make and model of car.
An example of numeric content that would be an exception is the number of connected devices within a finite number of connections. It's better for a user to pick a value of 0, 1, 2, 3 from a ring control than to instead have a numeric control and need to make sure the specified value is in range. |
|
If you use text rings for numeric content, do not create an item with text that represents a different numeric value. |
Recommended |
N/A |
For example, a selection of 2 assigned to the value 0 could confuse the user. |
|
Use the timestamp data type for time values in your API. |
Recommended |
N/A | N/A |
|
Use a double-precision value to specify the number of seconds for timeout values in your API. Use -1 to indicate that the diagram object has no timeout limit. |
Recommended |
N/A | N/A |
|
Use the waveform data type when your VI acquires or generates analog waveforms. |
Recommended |
N/A | N/A |
|
If your VI has a string input or output, consider whether another data type, such as an enum, might make your API easier to use. |
Recommended |
N/A | If the user needs to pick a day of the week, an enum with the seven days in it is easier to use than typing the name of the day as a string, because of possible problems with the case, spelling, and abbreviation. |
|
If you use a cluster as an input or output of your VI, make sure the cluster logically groups parameters. |
Recommended |
Do not use clusters only to reduce the number of inputs and outputs on your VI, because clustering things unnecessarily to reduce the number of inputs to the VI is not a logical organization. | N/A |
Related Information
- Best Practices for Designing and Developing an Application Programming Interface (API) in G Web Development Software
To develop an API to distribute to other users that is consistent with NI style recommendations for G content, refer to the following best practice guidelines:
- File Organization and Node Naming for Distributed APIs
Refer to the following table for best practices for organizing files and naming nodes.
- Component Organization for Distributed APIs
Refer to the following table for best practices for organizing components.
- Icons and Connector Panes for Distributed APIs
Refer to the following table for best practices for creating icons and connector panes.
- Panel Design for Distributed APIs
Refer to the following table for best practices for designing panels.
- Palette Taxonomy for Distributed APIs
Refer to the following table for best practices for palette taxonomy.
- Documentation for Distributed APIs
Refer to the following table for best practices for documenting an API.
- Error Message Design for Distributed APIs
Refer to the following table for best practices for designing error messages.
- API Design for Distributed APIs
Refer to the following table for best practices for designing VIs.