You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please consider introducing these (potentially breaking) changes:
Consistent Naming: select:/fields:, filter:/filters:, limit:/limits:. select is probably a typo or SQL-mindset mistake because there are only 2 methods with this parameter. Should just get rid of it. Since fields and limits aren't directly included in the API request (rather they form a JSONPath-like key along with referenced types), I suggest making all collection (e.g. [Limit]) parameters plural and single-type (e.g. Int) parameters singular.
Consolidate Data and Link Models: There really isn't a single reason that each response should inline their own named Data and Link structures since all have exactly the same properties. Apple's documentation isn't source code per-se so they give each structure a different name for readability, but in programming sense doing this is a huge waste of resources and hammers interoperability.
I can make these changes and PR (and adding some missing APIs along the way) but I'd like to ask for opinions first.
The text was updated successfully, but these errors were encountered:
Please consider introducing these (potentially breaking) changes:
Consistent Naming:
select:
/fields:
,filter:
/filters:
,limit:
/limits:
.select
is probably a typo or SQL-mindset mistake because there are only 2 methods with this parameter. Should just get rid of it. Sincefields
andlimits
aren't directly included in the API request (rather they form a JSONPath-like key along with referenced types), I suggest making all collection (e.g.[Limit]
) parameters plural and single-type (e.g.Int
) parameters singular.Consolidate
Data
andLink
Models: There really isn't a single reason that each response should inline their own namedData
andLink
structures since all have exactly the same properties. Apple's documentation isn't source code per-se so they give each structure a different name for readability, but in programming sense doing this is a huge waste of resources and hammers interoperability.I can make these changes and PR (and adding some missing APIs along the way) but I'd like to ask for opinions first.
The text was updated successfully, but these errors were encountered: