Answers.Body: <p>For historical reasons (namely cramming a bunch of fields from various entities into a flat array for e.g. a profile form) some fields in the database have a "unique_name" which is generally the entity prefixing the field name. For obscure reasons, the api v3 sometimes returns those "unique_names" instead of the regular field names.</p>
  
  <p>I personally hate the implementation of unique names in CiviCRM - it's inconsistent and confusing and if I have anything to say about it there will be <em>no</em> unique names in api v4!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-30T01:48:25.887Z
Answers.LastActivityDate: 2017-03-30T01:48:25.887Z
Answers.UserDisplayName: Coleman
Body: <p>I'm getting familiar with the API and having trouble understanding the pattern used to name fields. </p>
  
  <p>A call like <strong><code>CRM.api3('Address', 'get')</code></strong> makes sense to me because the fields in the result are (1) named consistently, and (2) each named exactly as they appear in MySQL. I see things like <code>street_address</code>, <code>location_type_id</code>, and <code>is_primary</code>. I like this.</p>
  
  <p>A call like <strong><code>CRM.api3('Activity', 'get')</code></strong> produces fields which make slightly less sense. I see <code>subject</code> and <code>status_id</code> which seem consistent. Good. But then I see <code>activity_date_time</code> and <code>activity_type_id</code> and become confused about why some fields are named with their entity as a prefix and some are not... <em>But</em> at the very least, all these field names are consistent with the column names in MySQL. Ok fine, I can live with that.</p>
  
  <p>But then when I look at the same call for <strong><code>Contribution</code></strong>, I get even more confused. I see fields like <code>contribution_check_number</code> which seem to have an <em>added</em> prefix, not present from MySQL. Why?</p>
  
  <p>And when I look at <strong><code>Participant</code></strong>, <em>all</em> the fields have a <code>participant_</code> prefix. Huh??</p>
  
  <p>Is there some sort of underlying pattern that can explain this madness to my logic-seeking brain?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-03-29T23:23:25.523Z
Comments.Text: I suspect the answer is, "Many cooks in the kitchen."
Comments.UserDisplayName: Jon G - Megaphone Tech
Tags: <api>
Title: What is the pattern used to name the fields accessible through the API?
ThreadText: # What is the pattern used to name the fields accessible through the API?
  
  (Asked by: username_0 on 2017-03-29)
  
  I'm getting familiar with the API and having trouble understanding the pattern used to name fields.
  
  A call like **`CRM.api3('Address', 'get')`** makes sense to me because the fields in the result are (1) named consistently, and (2) each named exactly as they appear in MySQL. I see things like `street_address`, `location_type_id`, and `is_primary`. I like this.
  
  A call like **`CRM.api3('Activity', 'get')`** produces fields which make slightly less sense. I see `subject` and `status_id` which seem consistent. Good. But then I see `activity_date_time` and `activity_type_id` and become confused about why some fields are named with their entity as a prefix and some are not... *But* at the very least, all these field names are consistent with the column names in MySQL. Ok fine, I can live with that.
  
  But then when I look at the same call for **`Contribution`**, I get even more confused. I see fields like `contribution_check_number` which seem to have an *added* prefix, not present from MySQL. Why?
  
  And when I look at **`Participant`**, *all* the fields have a `participant_` prefix. Huh??
  
  Is there some sort of underlying pattern that can explain this madness to my logic-seeking brain?
  
  **Tags:** api
  
  > **Comments:**
  > **username_1**: I suspect the answer is, "Many cooks in the kitchen."  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-03-30. Score: 1
  
  For historical reasons (namely cramming a bunch of fields from various entities into a flat array for e.g. a profile form) some fields in the database have a "unique\_name" which is generally the entity prefixing the field name. For obscure reasons, the api v3 sometimes returns those "unique\_names" instead of the regular field names.
  
  I personally hate the implementation of unique names in CiviCRM - it's inconsistent and confusing and if I have anything to say about it there will be *no* unique names in api v4!
  
  
  ---
  
  