We Keep Coding

Search for drive items with $expand parameter

I'm trying serach in a drive for driveItems. I have figured out how to search for driveItems in the API like this:
https://graph.microsoft.com/v1.0/sites/{siteId}/drives/{driveId}/search(q='test')
But for my application, I need more detailed information about the documents so I tried to use the $expand without any successful outcome.
Request to look up more details about a single driveItem:
https://graph.microsoft.com/v1.0/sites/{siteID}/drives/{driveId}/items/{itemId}/listItem/?expand=fields($select=Title,ID,etc..)
Is it possible to achieve all the fields I get from this request when I use the $expand parameter in Search for DriveItems within a drive? Or do I need to look up every single driveItem to get the additional parameters?
What I have tried:
https://graph.microsoft.com/v1.0/sites/{siteId}/drives/{driveId}/search(q='test')?expand=fields($select=id,title,etc..)

According to my research and testing, unfortunately, when I use the following graph api:
https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/items/{item-id}/?$expand=fields($select=id)
I got the error：
"message": "Parsing OData Select and Expand failed: Could not find a property named 'fields' on type 'microsoft.graph.driveItem'."
If you want to use the $expend parameter, I suggest you use the following Graph API:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items/{item-id}/?$expand=fields($select=id)

DB structure to handle chat groups similar to Telegram/FB Messenger

Currently doing a chat app where a user could join multiple chat groups, something similar to what Telegram and Facebook Messenger has. Pretty straight forward. We're mainly using Firebase database for storing the chat groups and message details.
Sample DB structure:
To only get the chat groups a user has:
root/
users/
chatGroups/
$uid/
$chatGroupId: true
We then get the details of the chat group from a different node, same with the latest chat message in that group:
root/
chatGroups/
entries/
$groupId/
group details here...
messages/
$groupId/
$messageId/
message details here..
Everything above to get the data for a single group item that looks something like this:
All works fine. We initially get at most 5 chat groups at first, then just sort the list. The problem lies where we have to listen for updates for the chat groups -- group with the most recent chat message would go to top of the list.
The structure we have listens only to the list of groups the specific user has -- we could detect groups joined (onChildAdded) and left (onChildRemoved) by the user, but it doesn't contain the timestamp we need to sort the chat group list by the most recent changes timestamp.
Has anyone tried this similar behavior with Firebase before (we're doing a client for both Android and Web -- Javascript)? Any ideas or suggestions would be appreciated. Let me know if you need some relevant details to make things clearer.

Because there is no auto-created metadata in Firebase about when a child was added, updated or deleted and also because those operations doesn't contain the information you are searching for, you need to create your own mechanism by adding the local timestamp for each operation or by writing a server-side timestamp.
There is another approach in which you can use denormalization. Add those chats to a new created section named uxChats. The chats will need to contain only the text message and the timestamp. If you are using FirebaseUI then you can reverse the order just using this lines of code:
LinearLayoutManager layoutManager = new LinearLayoutManager(getActivity());
layoutManager.setReverseLayout(true);
layoutManager.setStackFromEnd(true);
recyclerView.setLayoutManager(layoutManager)
Latest chat goes on top.
Hope it helps AL.

Is there a way in OKTA APIs to get users based on a list of userIds?

Is there a way in OKTA APIs to get users based on a list of userIds?
Using "search" feature we can search for users whose firstName or lastName or email starts with some value.
However if the use-case is something like searching for users whose id is in a list of given ids.
something like a where clase in sql.
Select * from users where id in ('23iuy234r223r','234235sefsfe','23534wsfwersef');
This could be really useful for calling list users api. So that we do not need to call get API for each user. Because naturally calling get multiple times can cause "API call exceeded rate limit due to too many requests" errors.
If there is a way to do this within existing okta apis or search features, Kindly suggest.

Using the filter query param, you can retrieve multiple users like so:
https://YOUR_ORG.okta.com/api/v1/users?filter=id eq "23iuy234r223r" or id eq "234235sefsfe" or id eq "23534wsfwersef"

Creating a Favorites list with shareable url using node an mongoDB

I've been searching a ton and maybe I'm using the wrong search terms, but essentially I want to have a user select items to add to a favorites list and then create a unique url they can share. An example can be found at http://www.sortfolio.com
When you click the "shortlist?" button at the bottom of an item it'll get added to the "My Shortlist (Your Favorites)" and when you click there it'll show what you've added to your favorites list and provide a shareable unique url with your favorites.
I have a MongoDB database and using Node with Express. I'm assuming you'd collect the items database id's and then make a get call to grab them, but how would I then create the unique shareable url. I think sortfolio is built with Ruby on Rails which I am not using. If anyone can point me in the right direction to replicate this type of functionality it would be a great help.

Hi just like you said you've to create one another Mongodb collection like favorites
{
favouriteid:unique id/if you want short uid the u can us npm uid,
Item:ref to production product collection
}
Then create an api for getting favorites according to favorites.
And in given site example user can shortlist and share item without login also. So in this case on Frontend side store shortlist in product in sessionstorage and if user want to see favorite list then add new favorite record with items fetching from sessionstorage or locals to rage. Provide sharable url which have unique sharable I'd. Above thing manage according to cookie basic.

RESTful API design with associations

I'm attempting to build an API for two resources, one with Users, and the other with Movies. Both resources have associations -- a User will have multiple Movies, and a Movie will have multiple Users. Presumably, I'd design my API something like this:
/api/users/
/api/users/:id
/api/users/:id/movies
/api/movies/
/api/movies/:id
/api/movies/:id/users
But here's the issue: I'm also using Backbone.js on the client side to fetch the API data. If If I create a Collection at
/api/users/:id/movies
then this will work well for GET requests, but POST and PUT requests would seemingly then be directed at:
/api/users/:id/movies/:id
But, seemingly, it would be better if it was posted to
/api/movies/:id
instead. Is that correct? How do people generally deal with RestFul associations?

Not sure what you mean by "POST and PUT requests would seemingly then be directed at...". Does Backbone.js automatically adds parameters to URLs? If so, you should look at configuring it so that it doesn't do that, because it won't be usable with a REST API. Links provided by a REST API should be the full ones, there's nothing to add or remove from them.
Finally, if you want to associate a movie with a user. You would POST the movie (or just its ID) to:
/api/users/:id/movies

It is correct. This is because "movies" are independent from "users". Movies can exist without users, so their relationship are actually "associative".
To create movies, you don't need users at all, so it makes more sense for the POST URI to create movie to be "POST /api/movies".
Alternative of association in RESTful API that I can think of is to have the list of movie IDs in the GET users API response, e.g. a property named "associatedMovieIDs" which has an array of strings of the IDs of the movies associated to the user.
With this, your APIs will then become:
/api/users/
/api/users/:id
/api/movies/
/api/movies/:id