TI API - New Requirement: Automatic mobility #218
Replies: 12 comments 5 replies
-
|
The new requirement foresees a new Intent: “Always provide the optimal routing from the user Device to an existing EAS instance” |
Beta Was this translation helpful? Give feedback.
-
|
Would this be like a single request to the platform to change the connection to the most suitable (optimal) EAS instance on a continuous basis - mostly triggered by device mobility. Definitely, it is a feasible enhancement for the Traffic Influence service. |
Beta Was this translation helpful? Give feedback.
-
|
@babunkj according to the previous discussion here: #217 (reply in thread) A feedback must be provided: "routing optimization performed due to mobility". |
Beta Was this translation helpful? Give feedback.
-
|
Intent: “Always provide the optimal routing from the Device to an existing EAS instance” Output: "Routing optimization performed due to Device mobility" |
Beta Was this translation helpful? Give feedback.
-
|
For Automatic Mobility I suggest to make it optional. I mean, the API Producer could provide “unsupported” as return value, when that feature is invoked by the API Consumer. This because maybe some Operator is not willing to provide this extra feature for some reason. I’m wondering if optional features have been addressed in CAMARA and how. Have we any example in other APIs for optional features? |
Beta Was this translation helpful? Give feedback.
-
|
Commonalities talks about Optional features here: In the Design Guidelines, chapter 5.2 (Backwards and Forward Compatibility), it is defined how to add new features with backward compatibility. In scope of this new requirement I suggest to adopt one this approaches:This is a list of changes to an API that DO NOT affect consumers:
This makes it optional for the API Consumer but it doesn't address the optionality for the operator to implement. I suggest to provide this feature with a specific operation and to document it as optionally supported by the API Producer. This means that the API Consumer can get back "unsupported" when invoking the new method for Automatic Mobility. I have open a discussion in Commonalities to address optional operations in the Guidelines: camaraproject/Commonalities#212 |
Beta Was this translation helpful? Give feedback.
-
|
I propose to implement the new Feature as optional using the already existing 501 error code as defined here: https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#32-http-response-codes Status code 501 (Not Implemented) indicates that the requested method is not supported by the server and cannot be handled. |
Beta Was this translation helpful? Give feedback.
-
|
The status code 501 has been defined to signal that an HTTP server does not support a particular HTTP method.
Using this code for items other than that is stretching its meaning quite far.
Kind regards,
Uwe
From: FabrizioMoggio ***@***.***>
Sent: Tuesday, May 28, 2024 10:46 AM
To: camaraproject/EdgeCloud ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [camaraproject/EdgeCloud] TI API - New Requirement: Automatic mobility (Discussion #218)
I propose to implement the new Feature as optional using the already existing 501 error code as defined here: https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#32-http-response-codes
…________________________________
Status code 501 (Not Implemented) indicates that the requested method is not supported by the server and cannot be handled.
—
Reply to this email directly, view it on GitHub<#218 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRTHPZNQUSCINGAQKRCOLZEQ73RAVCNFSM6AAAAABD4LOL3SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKNZYGE4DA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
@uwerauschenbach maybe I'm missing something. In my understanding 501 is exactly for that. We want to provide an additional optional feature that maybe is not implemented by all the Operators. The API Consumer calls an operation (invoking the related HTTP method) and if it that feature is not supported by the API Producer, it gets back 501 (Not Implemented). I can't see the stretching, but, as I said before, maybe I'm missing something, can you please help me to understand? Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
there is a discussion in Commonalities on this topic: "What should be returned when an endpoint is not implemented?" camaraproject/Commonalities#160 let's see its output. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Fabrizio,
Thanks for the pointer. I’ll check it and raise my point there. Then we can wait for the outcome of that discussion.
Still, I’d like to provide some more reasoning for my point: The 501 error is defined to signal that some HTTP method is not implemented. So it is a protocol-level error. On the contrary, if a feature is not implemented, this typically means that the payload body cannot be processed as it includes information whose processing is not implemented. For that, 400 Bad request has been designed.
As an example, assume you send a payload with content for an unsupported feature via PATCH and get a 501 error. The meaning of the 501 error is “the server doesn’t support PATCH” which is certainly not what we want to convey!
Kind regards,
Uwe
From: FabrizioMoggio ***@***.***>
Sent: Wednesday, May 29, 2024 2:16 PM
To: camaraproject/EdgeCloud ***@***.***>
Cc: Uwe Rauschenbach (Nokia) ***@***.***>; Mention ***@***.***>
Subject: Re: [camaraproject/EdgeCloud] TI API - New Requirement: Automatic mobility (Discussion #218)
there is a discussion in Commonalities on this topic: "What should be returned when an endpoint is not implemented?"
camaraproject/Commonalities#160<camaraproject/Commonalities#160>
let's see its output.
—
Reply to this email directly, view it on GitHub<#218 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRTHJOELBNDRQAZYCBHFLZEXBJVAVCNFSM6AAAAABD4LOL3SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKOJTGA4DM>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
… looking at the issue referred below, I need to correct my example.
The issue is not about features in a payload but about not implemented endpoints.
I still maintain my view that 501 is not applicable. For an endpoint not implemented, wouldn’t 404 Resource Not Found be the correct response code?
Kind regards,
Uwe
From: Uwe Rauschenbach (Nokia)
Sent: Friday, May 31, 2024 11:20 AM
To: camaraproject/EdgeCloud ***@***.***>; camaraproject/EdgeCloud ***@***.***>
Cc: Mention ***@***.***>
Subject: RE: [camaraproject/EdgeCloud] TI API - New Requirement: Automatic mobility (Discussion #218)
Hi Fabrizio,
Thanks for the pointer. I’ll check it and raise my point there. Then we can wait for the outcome of that discussion.
Still, I’d like to provide some more reasoning for my point: The 501 error is defined to signal that some HTTP method is not implemented. So it is a protocol-level error. On the contrary, if a feature is not implemented, this typically means that the payload body cannot be processed as it includes information whose processing is not implemented. For that, 400 Bad request has been designed.
As an example, assume you send a payload with content for an unsupported feature via PATCH and get a 501 error. The meaning of the 501 error is “the server doesn’t support PATCH” which is certainly not what we want to convey!
Kind regards,
Uwe
From: FabrizioMoggio ***@***.******@***.***>>
Sent: Wednesday, May 29, 2024 2:16 PM
To: camaraproject/EdgeCloud ***@***.******@***.***>>
Cc: Uwe Rauschenbach (Nokia) ***@***.******@***.***>>; Mention ***@***.******@***.***>>
Subject: Re: [camaraproject/EdgeCloud] TI API - New Requirement: Automatic mobility (Discussion #218)
there is a discussion in Commonalities on this topic: "What should be returned when an endpoint is not implemented?"
camaraproject/Commonalities#160<camaraproject/Commonalities#160>
let's see its output.
—
Reply to this email directly, view it on GitHub<#218 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRTHJOELBNDRQAZYCBHFLZEXBJVAVCNFSM6AAAAABD4LOL3SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKOJTGA4DM>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
I see. If the Operator doesn't implements the endpoint, I agree with you. I think that, to make it easier for the Developer, we could explain in the documentation that the endpoint provides an operation that is optional for the Operator to implement. The endpoint is anyway implemented and even if the related operation is not available, the API Producer provides back an explicit message. It seems to me more "developer friendly" than not implementing the endpoint at all. The API Consumer can invoke the endpoint, that is always exposed, if it gets back "Not Implemented" as output (maybe via Error Code, 501) he can manage the application flow consequently invoking the TI API each time the UE moves. This new endpoint, if fully supported, provides the operation: "automatic mobility": it is the API Producer that keep the UE in the right UPF. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Fabrizio,
What do you mean by “The endpoint is anyway implemented and even if the related operation is not available, the API Producer provides back an explicit message.”?
Do you mean “HTTP method” when you write “operation”? In other words, do you foresee that the endpoint may respond to some HTTP methods but not to all?
In that case, I believe “405 Method not allowed” would be the right code. It signals that a resource (which exists) does not support a particular method; as opposed to 501 which signals the method is globally not supported.
For managing the application flow, I’d say the 404 code is as informative for the developer for controlling the application flow (if endpoint /xyz gives 404 error, one can assume that the related information/functionality is not available).
Kind regards,
Uwe
From: FabrizioMoggio ***@***.***>
Sent: Friday, May 31, 2024 3:38 PM
To: camaraproject/EdgeCloud ***@***.***>
Cc: Uwe Rauschenbach (Nokia) ***@***.***>; Mention ***@***.***>
Subject: Re: [camaraproject/EdgeCloud] TI API - New Requirement: Automatic mobility (Discussion #218)
I see, if the Operator doesn't implements the endpoint, I agree with you. I think that, to make it easier for the Developer, we could explain in the documentation that the endpoint provides an operation that is optional for the Operator to implement. The endpoint is anyway implemented and even if the related operation is not available, the API Producer provides back an explicit message. It seems to me more "developer friendly" than not implementing the endpoint at all. The API Consumer can invoke the endpoint, that is always exposed, if it gets back "Not Implemented" as output (maybe via Error Code, 501) he can manage the application flow consequently invoking the TI API each time the UE moves. This new endpoint, if fully supported, provides the operation: "automatic mobility": it is the API Producer that keep the UE in the right UPF.
—
Reply to this email directly, view it on GitHub<#218 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRTHINDIS2Q3S7G6SMZHTZFB4MXAVCNFSM6AAAAABD4LOL3SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMMJYHAZDI>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
I see your point, maybe 404 or 405 are better suited. About naming the things :-). This is my understanding: Operation: the action, the feature I want to provide |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the explanation, I have the same understanding of the naming.
Kind regards,
Uwe
From: FabrizioMoggio ***@***.***>
Sent: Friday, May 31, 2024 4:11 PM
To: camaraproject/EdgeCloud ***@***.***>
Cc: Uwe Rauschenbach (Nokia) ***@***.***>; Mention ***@***.***>
Subject: Re: [camaraproject/EdgeCloud] TI API - New Requirement: Automatic mobility (Discussion #218)
I see your point, maybe 404 or 405 are better suited.
About naming the things :-). This is my understanding:
Operation: the action, the feature I wont to provide
HTTP method: the operation con be implemented with a POST or a PUT etc.
endpoint: the path in the YAML
—
Reply to this email directly, view it on GitHub<#218 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRTHKDE6O7MOR7XOGGPNDZFCAHJAVCNFSM6AAAAABD4LOL3SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMMJZGMYDA>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
According to : camaraproject/Commonalities#160 (comment) Possible solution: is to use 404 (resource not found). We could define a new resource to support the new Intent (automatic mobility) and if it is not supported by the Operator's implementation the new endpoint for the new Intent returns 404. |
Beta Was this translation helpful? Give feedback.
-
The AF invokes the API with a latency requirement. When the UE moves, the platform selects the best UPF and moves the anchor point automatically.
Leveraging on the same southbound APIs, this optional feature can provide the UE with the optimal UPF connection when the user moves among different geographical areas. A notification is provided to the API Consumer when a new UPF is engaged.
Beta Was this translation helpful? Give feedback.
All reactions