How to detect real time change in API response

I don't know Flux, and my answer is "it depends".

Edit with summary: I would choose between either (A) including attendee resrouces directly under meetings (and not optimizing as you have done), or (B) not include them at all and only provide URIs of the attendee resources. Choice (A) is a reasonable compromise in my eyes.

If you're aiming to be as RESTful as possible, including two top-level resources (meetingsand allUsersIntersectedByMeetings) don't fit well.

Instead, you could have your /meetings collection of meetings that's responsible for returning meetings. A network maybe-not-efficient way is to add links from a meeting resource to the URL of each of its attendees.

It's possible then that your browser will cache attendees (people) that it has already request in the past.

Rather than links, you can include the attendee objects direclty, like:

{ "meetings": [ { "id": 1, "attendees": [ { "id": 1, "name": "Oscar" } ] ] }

By the way, the "JSON API" standard uses an includes section like your original example. I'm not sure how RESTful or not that approach is.

It sounds like you are talking about a 'single page app'

This term is used to refer to websites where all or most of the actions you take are accomplished via client side javascript AJAX calls, which retrieve json, convert that json to html and update the page

rather than:

Having the browser request a new html page which is returned and shown by the browser, discarding the old page.

Although I agree there are downsides to this approach, it is now the de facto standard architecture for website design. The simple reason being that AJAX gives a clearly better user experience over page loads.

Several javascript frameworks such as react and angular are available to make this approach easy to implement.

So, most 'single page apps' are NOT all done on a single page. Admin pages, Settings etc are in my experience usually split off, in to what is effectively a separate 'single page app'. ie you have a Admin.html which also uses angular or whatever and has a set of apis to do its in page functionality.

This makes it easier to separate out the concerns and address some problems that single page apps tend to have with authentication.

The user experience is not really affected, because changing between these sections of the site is not something they do often and is seen as a 'big step' with the entire page changing.

However, you should consider carefully where this approach is sensible. having some forms submit via standard http and some via your js framework would seem to me not to add any benefit. If you are using a framework, stick to it and use it for everything. If you are doing old skool html, stick to that. combining both approaches will simply mean you get the downsides of both.