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??

it's the same guideline. camelcase is also used for attributes.

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??

Hi Matthieu, 

Just to be pedantic  - how should we treat attributes that are provided as name–value pairs? Is there any guideline on this. 

Technically, in those cases the attribute name itself is actually the value of the "name" field within the JSON payload.

I also see a different thread - Urgent: Guidelines for using Camel Case or Lower Case for TMF API's | Open APIs but it's unclear whether this is any guideline. 

Would appreciate your clarification for attributes like below.

Regards

Anuraag 

it's the same guideline. camelcase is also used for attributes.

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??