Open APIs

Hello,

I would like to get confirmation of how to use the Error payload that appears in the OpenAPI schemas on GitHub.
Is my thinking below correct? Are there any formal specifications?

Specifically, I think ...
The "code" is for an error code ~ some application specific value.
The "reason" and "message" are for human consumption, so I assume they are text that supports the code. I.e. each code might have a reason and message that a user can use to better understand the code. Reason and message basically boil down to "short message", "long message".
The "status" looks to be analogous to the Microsoft IIS sub-codes (e.g. 400.1 400.2 etc) - i.e. a mechanism to categorise the error in the language of HTTP? A way to further slice up the HTTP status.

If we wish to return structured error data, i.e. more than a single code, then we would extend/subclass the object in the usual way (@type. @baseType).
 
Does this look right?

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------

Hi,

    You can refer to TMF630 - REST_API_Design_Guidelines, Section:3 for guidelines on Error type.

  As per TMF630,
   code: Application related code
   reason: Text that explains the reason for error
   message: Text that provide more details and corrective actions related to the error.
   status: http error code extension like 400-2

Regards

------------------------------
Meher Irukoti
Tata Consultancy Services
------------------------------

Original Message:
Sent: Apr 22, 2020 19:02
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

Hello,

I would like to get confirmation of how to use the Error payload that appears in the OpenAPI schemas on GitHub.
Is my thinking below correct? Are there any formal specifications?

Specifically, I think ...
The "code" is for an error code ~ some application specific value.
The "reason" and "message" are for human consumption, so I assume they are text that supports the code. I.e. each code might have a reason and message that a user can use to better understand the code. Reason and message basically boil down to "short message", "long message".
The "status" looks to be analogous to the Microsoft IIS sub-codes (e.g. 400.1 400.2 etc) - i.e. a mechanism to categorise the error in the language of HTTP? A way to further slice up the HTTP status.

If we wish to return structured error data, i.e. more than a single code, then we would extend/subclass the object in the usual way (@type. @baseType).

Does this look right?

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------

Thanks Meher,

I should have thought of checking the general guidelines.

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------

Original Message:
Sent: Apr 23, 2020 04:23
From: Meher Irukoti
Subject: Any documentation on the Error structure?

Hi,

    You can refer to TMF630 - REST_API_Design_Guidelines, Section:3 for guidelines on Error type.

  As per TMF630,
   code: Application related code
   reason: Text that explains the reason for error
   message: Text that provide more details and corrective actions related to the error.
   status: http error code extension like 400-2

Regards

------------------------------
Meher Irukoti
Tata Consultancy Services

Original Message:
Sent: Apr 22, 2020 19:02
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

Hello,

I would like to get confirmation of how to use the Error payload that appears in the OpenAPI schemas on GitHub.
Is my thinking below correct? Are there any formal specifications?

Specifically, I think ...
The "code" is for an error code ~ some application specific value.
The "reason" and "message" are for human consumption, so I assume they are text that supports the code. I.e. each code might have a reason and message that a user can use to better understand the code. Reason and message basically boil down to "short message", "long message".
The "status" looks to be analogous to the Microsoft IIS sub-codes (e.g. 400.1 400.2 etc) - i.e. a mechanism to categorise the error in the language of HTTP? A way to further slice up the HTTP status.

If we wish to return structured error data, i.e. more than a single code, then we would extend/subclass the object in the usual way (@type. @baseType).

Does this look right?

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------

For info - the description of errors is actually in TMF630 Part 1, not part 3.
(I am looking at version 17.5.1)

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------

Original Message:
Sent: Apr 23, 2020 04:40
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

Thanks Meher,

I should have thought of checking the general guidelines.

------------------------------
Alasdair MacLeod
BT Group plc

Original Message:
Sent: Apr 23, 2020 04:23
From: Meher Irukoti
Subject: Any documentation on the Error structure?

Hi,

    You can refer to TMF630 - REST_API_Design_Guidelines, Section:3 for guidelines on Error type.

  As per TMF630,
   code: Application related code
   reason: Text that explains the reason for error
   message: Text that provide more details and corrective actions related to the error.
   status: http error code extension like 400-2

Regards

------------------------------
Meher Irukoti
Tata Consultancy Services

Original Message:
Sent: Apr 22, 2020 19:02
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

Hello,

I would like to get confirmation of how to use the Error payload that appears in the OpenAPI schemas on GitHub.
Is my thinking below correct? Are there any formal specifications?

Specifically, I think ...
The "code" is for an error code ~ some application specific value.
The "reason" and "message" are for human consumption, so I assume they are text that supports the code. I.e. each code might have a reason and message that a user can use to better understand the code. Reason and message basically boil down to "short message", "long message".
The "status" looks to be analogous to the Microsoft IIS sub-codes (e.g. 400.1 400.2 etc) - i.e. a mechanism to categorise the error in the language of HTTP? A way to further slice up the HTTP status.

If we wish to return structured error data, i.e. more than a single code, then we would extend/subclass the object in the usual way (@type. @baseType).

Does this look right?

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------

Yes, I was also refer to 3. Uniform Contract Methods and Media Types of part 1.

------------------------------
Meher Irukoti
Tata Consultancy Services
------------------------------

Original Message:
Sent: Apr 23, 2020 05:03
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

For info - the description of errors is actually in TMF630 Part 1, not part 3.
(I am looking at version 17.5.1)

------------------------------
Alasdair MacLeod
BT Group plc

Original Message:
Sent: Apr 23, 2020 04:40
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

Thanks Meher,

I should have thought of checking the general guidelines.

------------------------------
Alasdair MacLeod
BT Group plc

Original Message:
Sent: Apr 23, 2020 04:23
From: Meher Irukoti
Subject: Any documentation on the Error structure?

Hi,

    You can refer to TMF630 - REST_API_Design_Guidelines, Section:3 for guidelines on Error type.

  As per TMF630,
   code: Application related code
   reason: Text that explains the reason for error
   message: Text that provide more details and corrective actions related to the error.
   status: http error code extension like 400-2

Regards

------------------------------
Meher Irukoti
Tata Consultancy Services

Original Message:
Sent: Apr 22, 2020 19:02
From: Alasdair MacLeod
Subject: Any documentation on the Error structure?

Hello,

I would like to get confirmation of how to use the Error payload that appears in the OpenAPI schemas on GitHub.
Is my thinking below correct? Are there any formal specifications?

Specifically, I think ...
The "code" is for an error code ~ some application specific value.
The "reason" and "message" are for human consumption, so I assume they are text that supports the code. I.e. each code might have a reason and message that a user can use to better understand the code. Reason and message basically boil down to "short message", "long message".
The "status" looks to be analogous to the Microsoft IIS sub-codes (e.g. 400.1 400.2 etc) - i.e. a mechanism to categorise the error in the language of HTTP? A way to further slice up the HTTP status.

If we wish to return structured error data, i.e. more than a single code, then we would extend/subclass the object in the usual way (@type. @baseType).

Does this look right?

------------------------------
Alasdair MacLeod
BT Group plc
------------------------------