Current ACS call session list and force to end it by REST - azure-communication-services

I'm integrating ACS video call into my service (NodeJs backend, React front).
I want to allow ACS video call session only for a scheduled time period, then force to end it if it is over.
However I cannot find the way of implement followings (or REST API)
list current call sessions
list participants of each sessions.
force to stop/end a session by group id or any call ID
webhooks/callback being called when the session closes and when the participant leaves session.
Could you please give me some hint or advice?
Much appreciated.
Jin

You can use the Call Automation to join or create a new call. Your app can join either as a participant of the call or act out of the call. Each option offers different capabilities described here.
The good news is that both options offer the capability to add and remove participants to/from the call:
Call Connections - Remove Participant
Server Calls - Remove Participant
If you decide to use the In-Call (App-Participant) APIs, can you specify the callbackUri in the CreateCallOptions or JoinCallOptions. On this URI, you can listen to events (webhooks) such as Participants updated and deserialize the information about them. There is a comprehensive quickstart app available on GitHub showcasing the concept of callback URIs on the call recording capabilities (see the CallRecordingController.cs and Utils.ts in the public-preview branch).
If you decide to use the Out-of-Call APIs, then you need to keep track of the participant IDs yourself.
Currently, the CallingServer SDKs are currently available only for .NET and Java so you'll have to use the REST API.

Related

How to store and access request specific data in Akka HTTP?

I need a mechanism to store and access request specific data in Akka HTTP. Is it possible without sending values around to each actor that is called from the route?
Let's say I want to log performance of all operations, including request id, so I'm able to search logs by request id. So when logging inside actor, it would be great to do something like Request.id.
Note that API does not implement session, since this is a specific service which runs behind main API (which is doing authentication etc).
Is there any library or built in way suitable for this?
Thanks in advance

Webhook and API (Defination & Diffrences)

I want to know about webhook (what is webhook). What is the application of webhook (a real world scenario). Besides, what are the differences between webhook & API?
An API is a standardised way of communicating with a service. You've tagged REST in your question so I'll focus on RESTful APIs using HTTP but it is important to know that API is a very generic term.
In the REST world everything is a resource and you use the HTTP methods to define what action you want to take on or apply to that resource. For example, to list all the users on GitHub you would send a GET request to https://api.github.com/users. The URL (specifically the /users part) defines what resource you are interested in. Here the resource is a collection of all the users. There's other methods you can use; such as PUT to create or update a resource. To learn more about the different methods you can read the HTTP specification.
Webhooks are often used in conjunction with APIs but they are focused on events. They allow a service to send out 'notifications' when an event happens or some condition is met.
GitHub is again a good example of what webhooks are used for. Say I'm building a service which sends out an email every time someone leaves a comment on an issue in GitHub. I could use the GitHub API (like above) to list all of the comments on an issue and then check if there have been any new comments since the last time I checked. I can then just repeat this request every few seconds. This is known as polling. The issue here is that most of the time I'm checking the result is not going to change. This is going to be a waste of resources.
Webooks allow for Event-Driven Programming. Instead of randomly checking I can instruct GitHub to send my service a HTTP request every time a comment is added: aka a webhook. In this architecture I only have to send a request to GitHub's API when I know for sure that a new comment has been left.
Overall, you cannot really compare APIs and webhooks. The link between them is simply that webhooks send requests to APIs.

Handling User Preferences/States in REST API

We're starting to migrate our Website to a REST Service based system and are in the process of developing the core right now.
In our current setup a user has one or more "accounts" assigned which define what data he can see on the website. Only one account can be active for a given user at any time. Right now we store the selected account in the database and use it to filter all queries.
Now I'm not sure how to handle this properly in a REST environment. Possible solutions I found are:
Sending the requested account with every request
Storing the current account in the auth token. (We're using JWT for that)
Having the current account stored on the server and calling a specific resource to change it
Each of these has its pros and cons for our setup. Currently we're using the 3rd approach in our Website. But what would be the correct way to handle such a thing in a REST environment?
Yea the design you are dealing with is fairly bad, and what you really want to do is remove the state completely out of this system.
For that reason the first option is by far superior:
Sending the requested account with every request
If this is simply an id, there's a very simple way to do this, just prefix all your (relevant) routes / uris with this account id. For example:
http://api.example.org/accounts/{id}/...
This way the 'state' is maintained by virtue of which url you are accessing, and the server can be unaware of the state.

How facebook knows all user connections so fast?

I'm developing a service, that uses social graph.
There is a separate module, that manages user connections, that is basically responsible for all related operations. In some services, you need to know all user connections, to provide correct responses.
The way I see it there are 4 possible options to implement this:
Server based connection support.
1.1. Each time social graph data requested ask for friend list from the module, and process corresponding response.
1.2. Have internal cache with Key - playerID, Value - all player connections, add responsibility to update this cache to connection module, and use it instead of referring to this module.
Client based connection support.
2.1. Add a special Cookie with the list of all friends, so that server could just read that Cookie and provide needed information, without talking to the external module. (This can be secured, by for example providing some signature for the Cookie, and optimised by adding some path, for all the connections related data)
2.2. Add a connection management layer in Client, so it would explicitly request all needed information, by providing a list of connections on each request.
As I look at facebook Cookies, there is a fr cookie, which I can speculate used for this kind of functionality.
How facebook solves this?
If you just want to maintain a list of friends for each user you don't need a full social graph. A simple list of friends stored in your database would work fine.
Client-side storage is typically only for caching or session data, you don't want your users losing their friend list because they re-installed their browser or switched computers.
If you do want to implement a full social graph have a look for a graph DB. Neo4J is one I've used and is fairly easy to get started on.

How do I track users(clients) in a REST GET calls

We have a Public REST application which has a lot of GET's from the clients . We have a way to track the POST calls but we do not have a way to track where the user has come for the GET calls .
Our intention is to have some client specific business rules if we are able to decide where the call has come from ?
Returning different responses to a GET based on where the request comes from is not a great idea. Could you not POST the tracking id to an endpoint and have it redirect to a GET of ResourceA for this client and ResourceB for another client.
If you only want to track the GET requests then you could use cookies to identify the client. However, I would not recommended using the cookies to drive business logic.