Answers.Body: <p>The API should really only apply logic that can be derived from the metadata - ie. the api applies defaults, enforces required fields, maps names of option values to the values. </p>
  
  <p>Any logic that is 'business logic' should be in the BAO. ie. the api should be a thin layer over the BAO on the create &amp; delete functions &amp; anything other than GET (where the BAO can basically be considered to be deprecated where GET type functions exist).</p>
  
  <p>In addition the api layer has the function of providing compatibility - ie. if a field name changes it is up to the api layer to make this seamless to api users. Realistically this could also be done via metadata in the xml and perhaps that fact explains why it is in the api layer. The api.aliasing, for example, is currently declared in the api but could be declared in the xml. The compatibility functionality should be reset when the version increments (perhaps an argument for keeping the metadata in the api)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-07T05:14:02.430Z
Answers.Text: I wonder who user4278 is??
Answers.UserDisplayName: ErichBSchulz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-07T09:24:51.153Z
Answers.Text: Wish I could upvote @ErichBSchulz 's comment.
Answers.UserDisplayName: JohnFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-07T02:20:06.690Z
Answers.LastActivityDate: 2017-02-07T02:20:06.690Z
Answers.UserDisplayName: user4278
Body: <p>I'm started to look at both the API and BAO classes.</p>
  
  <p>It seems there is a degree of scope overlap for the business logic.</p>
  
  <p>It seems to me that most logic should live in the BAO - but am I missing something? When does logic belong in the API but not in the BAO?</p>
  
Tags: <php><coding-standards>
Title: BAO vs API layer
ThreadText: # BAO vs API layer
  
  (Asked by: username_0 on 2017-02-06)
  
  I'm started to look at both the API and BAO classes.
  
  It seems there is a degree of scope overlap for the business logic.
  
  It seems to me that most logic should live in the BAO - but am I missing something? When does logic belong in the API but not in the BAO?
  
  **Tags:** php, coding-standards
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-02-07. Score: 2 | Accepted answer
  
  The API should really only apply logic that can be derived from the metadata - ie. the api applies defaults, enforces required fields, maps names of option values to the values.
  
  Any logic that is 'business logic' should be in the BAO. ie. the api should be a thin layer over the BAO on the create & delete functions & anything other than GET (where the BAO can basically be considered to be deprecated where GET type functions exist).
  
  In addition the api layer has the function of providing compatibility - ie. if a field name changes it is up to the api layer to make this seamless to api users. Realistically this could also be done via metadata in the xml and perhaps that fact explains why it is in the api layer. The api.aliasing, for example, is currently declared in the api but could be declared in the xml. The compatibility functionality should be reset when the version increments (perhaps an argument for keeping the metadata in the api)
  
  > **Comments:**
  > **username_0**: I wonder who username_1 is??  
  > **username_2**: Wish I could upvote @username_0 's comment.  
  
  ---
  
  