Open APIs

While working for oneof the business use case, when i was referring to TMF 717: Customer360

object MediumCharacteristic has an attribute postCode (camel case).

But the same attribute in TMF673 - GeographicAddress is represented as postcode (small case). 

There are multiple APIs that uses these objects by reference and by value and hence carrying over this inconstancy in them.

looking at all other attributes camel-case seems to be right way.

thoughts??

you can read the API user guide (TMF 630).

2.3  Resource Naming Convention

Names in URI (tasks, individual resources, etc.) MUST be camel case or lower case.

e.g. /account/billSummary/billDetail or /account/billSummary/billdetail

While working for oneof the business use case, when i was referring to TMF 717: Customer360

object MediumCharacteristic has an attribute postCode (camel case).

But the same attribute in TMF673 - GeographicAddress is represented as postcode (small case). 

There are multiple APIs that uses these objects by reference and by value and hence carrying over this inconstancy in them.

looking at all other attributes camel-case seems to be right way.

thoughts??

Hi Matthieu,

Yes, you are right, the TMF 630 contains the Resource Naming Convention subsection. But question was not about resource naming but about attribute naming. And, unfortunately, TMF 630 does not provide any suggestions for attribute naming.

Based on the fact that the TMF OpenAPIs de-facto use camelCase for attribute naming, I would suggest renaming the "postcode" attribute (lowercase notation) to "postCode" (camelCase notation) in the TMF 637 Geographic Address Management API to be consistent with other TMF APIs. At least it can be done for the v5 of the TMF 637 API specification.

you can read the API user guide (TMF 630).

2.3  Resource Naming Convention

Names in URI (tasks, individual resources, etc.) MUST be camel case or lower case.

e.g. /account/billSummary/billDetail or /account/billSummary/billdetail

While working for oneof the business use case, when i was referring to TMF 717: Customer360

object MediumCharacteristic has an attribute postCode (camel case).

But the same attribute in TMF673 - GeographicAddress is represented as postcode (small case). 

There are multiple APIs that uses these objects by reference and by value and hence carrying over this inconstancy in them.

looking at all other attributes camel-case seems to be right way.

thoughts??