Juniper Connect Fields are snake_case

Both camelCase and snake_case are commonly used in JSON APIs, and the choice often depends on personal or team preferences, as well as any established conventions within the development community or organisation.

The Juniper Connect API uses snake_case for all field names.

Consistency with Database Naming:

SQL databases, especially those following common conventions like PostgreSQL or MySQL, often use snake_case for table and column names. Using snake_case in your JSON API makes the field names consistent with your database schema, creating a more seamless integration between your API and the underlying data store.

Easier Mapping to SQL Queries:

Many Object-Relational Mapping (ORM) tools or query builders used with SQL databases automatically map snake_case names to their corresponding database columns. This consistency simplifies the mapping process and reduces the need for explicit configuration, making your code more intuitive and easier to maintain.

Readability in SQL Queries:

When writing SQL queries, using snake_case for column names aligns with the typical SQL convention, enhancing the readability of your queries. This consistency can be particularly beneficial when developers need to switch between working with SQL queries and JSON API interactions.

Avoiding Quoting Issues:

Some databases are case-insensitive by default, and using snake_case can help avoid issues related to case sensitivity in queries. Additionally, in databases that treat names as case-sensitive, using snake_case eliminates the need for quoting field names in queries.

Community and Tool Support:

Many SQL-related tools and libraries are designed with snake_case conventions in mind.

Adopting snake_case aligns with established practices in the broader development community and can make it easier to integrate with existing tools and libraries.

Boolean Fields

Use the Positive Affirmative Form.

Example: is_active, is_enabled, has_permission

Avoid Negations

Example (avoid) : is_not_active, is_not_enabled, has_no_permission

Use Present Tense

Example: is_running, has_access

Avoid Redundancy

Avoid adding redundant information in the boolean field names. The name should be concise while still conveying its purpose.

Example (avoid): is_enabled_flag

Enumeration Fields

Use Singular Form:

Name your enumeration fields in the singular form to represent a single instance of the enumeration.

Example: status, type, role

Consistent Casing:

Maintain consistency in the casing convention (all lowercase, snake_case) used for enumeration field names, just as you would for other fields.

Example (snake_case): relationship_to_child : biological_father

Be Descriptive:

Use names that are descriptive and convey the meaning of the enumeration values.

Example: Instead of using generic terms like value or enum, use something more specific like status with values such as pending, approved, rejected.

Avoid Abbreviations:

Avoid using abbreviations unless they are widely understood.

Example (avoid): type: “mgr” (use type: “manager” instead)

Avoid Numeric Enumerations:

If possible, avoid using numeric values for enumerations, as they can be less descriptive and more prone to misinterpretation.

Example (avoid): status: 1 (use status: pending instead)

Date and Time Fields

It is very important to use the correct data types with the right precision for date and time fields. The precision of the field should be based on the use case and the level of accuracy required.

Use appropriate date types:

Date and times should never be stored as strings. Use the appropriate date type for the field.

Never store the time component where a simple date will suffice:

Example (avoid) : date_of_birth : 2011-05-01T00:00:00Z