Hello Arora, Nancy,
Thanks for reaching out!
When you list events (GET /me/events
), you get a non-expanded list of items in the calendar. What that means is that if you have recurring events, you will only get the series master in your results. It would be up to you to read the recurrence pattern and expand the event.
GET /users/{id | userPrincipalName}/calendar/events
return events from the default calendar of a specific user.
When you list a calendar view (GET /me/calendarview?...
), you get an expanded list of items. That means the server does the work to expand any recurring events and build a "view" of your calendar. So, in this case if you have a recurring event, instead of getting the series master, you will get one or more occurrences of the series (depending on how many times it repeats in your view window). Because of this expansion work, you must provide a start and end time to put some sort of bounds on the call.
Another way of looking at it is the calendar view is more like what you're used to seeing when you view your calendar in Outlook.
By default, you're limited to 10 items in the response. You should also see in your response an @odata.nextLink, which is the URL you can use to request the next page of results (again, 10 being the default page size). You can increase your page size by using the $top parameter, up to a maximum of 1000 (IIRC).
Get /me/calendar/calendarView?startDateTime=2023-03-01T00:00:00.0000000&endDateTime=2023-03-08T00:00:00.0000000&$top=1000
Recommendations/Best Practices while using CalendarView:
- The recommended time window used in the CalendarView should ideally be not more than one week. This is because CalendarView API does a lot of processing in the backend before providing the results.
- Using $skip and/or $top in the API query parameters doesn't necessarily skip the calculations needed for getting the results for this API. Hence, if a larger window of CalendarView is to be queried, the client should make CalendarView API calls with different time windows, rather then using a larger time window and relying on $skip and $top.
- Server-side time limit for getting the results of any REST API is 2 minutes (120 seconds), after which the API request gets terminated and the client will receive a 500 Status Code. On observing such long delays, the client should reduce the time window being queried for and try again.
- The $select on the API should preferably contain only on-page properties (list of which can be viewed here named as HardCodedProperties).
Example : $select=Id,ChangeKey,Categories,OriginalStartTimeZone,OriginalEndTimeZone,iCalUId,HasAttachments,Subject,IsCancelled,IsOrganizer,ResponseRequested,SeriesMasterId,ShowAs,Type,IsDraft,Start,End
You could exclude properties you don't need for faster responses. - If the time window has numerous recurring series events, CalendarView needs to load all the instances in that time frame which makes it less performant. It is recommended for the user to work with EEEs and get their old recurring meetings archived for better performance.
Hope this helps.
If the answer is helpful, please click Accept Answer and kindly upvote. If you have any further questions about this answer, please click Comment.