Add get API for SIP Dispatch Rules. #913
Conversation
🦋 Changeset detectedLatest commit: 846407f The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR 💥 An error occurred when fetching the changed packages and changesets in this PR |
protobufs/livekit_sip.proto
Outdated
| @@ -63,6 +63,7 @@ service SIP { | |||
| rpc DeleteSIPTrunk(DeleteSIPTrunkRequest) returns (SIPTrunkInfo); | |||
|
|
|||
| rpc CreateSIPDispatchRule(CreateSIPDispatchRuleRequest) returns (SIPDispatchRuleInfo); | |||
| rpc GetSIPDispatchRule(GetSIPDispatchRuleRequest) returns (GetSIPDispatchRuleResponse); | |||
There was a problem hiding this comment.
I think that for other services, we've overloaded the List API and added an optional "stuff_to_list_id" parameter to that request.
There was a problem hiding this comment.
no preference here from me.. I think over time the list/get APIs might diverge (with pagination/etc)
There was a problem hiding this comment.
In general I prefer to have a separate get API, because it allows the service to send "not found" error directly, instead of requiring client checking the list and throwing that error.
But I see the point here. Reusing list API also allows seamless batching support, which is nice. Definitely worth it.
I rewrote the PR to add a few filters to list requests. The storage implementation won't need to support them all, because it will apply Filter after getting an initial list. Same for CLI / Go SDK - it will filter results after receiving them, so as soon as we update protocol in the client, it will immediately use new filter logic, even if the server doesn't support it yet.
No description provided.