<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Waiting for Web API commands with side-effects to complete in Spotify for Developers</title>
    <link>https://community.spotify.com/t5/Spotify-for-Developers/Waiting-for-Web-API-commands-with-side-effects-to-complete/m-p/5608560#M9961</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;using the Web API, I noticed that requests to commands with side effects end earlier than the related changes appear. For example, if we call the endpoint&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/get-queue" target="_self"&gt;Get the User's Queue&lt;/A&gt;&amp;nbsp;immediately after&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/add-to-queue" target="_self"&gt;Add Item to Playback Queue&lt;/A&gt;, we'll sometimes get&amp;nbsp;the state of the queue, in which our item is not yet present.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Consequently, to get the contents of the queue after the addition has fully processed, I have to poll in a loop (with possible backoffs), calling&amp;nbsp;&lt;FONT face="courier new,courier"&gt;/me/player/queue&lt;/FONT&gt; &amp;nbsp;until my element's uri comes up in the output (which is of course an arbitrary heuristic).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It seems that many endpoints exhibit this "non-blocking" behavior, returning a &lt;FONT face="courier new,courier"&gt;2XX&lt;/FONT&gt; status code as soon as the action has been accepted for execution, for example:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/pause-a-users-playback" target="_self"&gt;Pause Playback&lt;/A&gt;&amp;nbsp;sometimes returns before a call to&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/get-information-about-the-users-current-playback" target="_self"&gt;Get Playback State&lt;/A&gt;&amp;nbsp;shows the&amp;nbsp;&lt;FONT face="courier new,courier"&gt;is_playing&lt;/FONT&gt;&lt;SPAN&gt; property as false,&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;DIV&gt;similarly&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/start-a-users-playback" target="_self"&gt;Start/Resume Playback&lt;/A&gt;&amp;nbsp;for&amp;nbsp;&lt;FONT face="courier new,courier"&gt;is_playing&lt;/FONT&gt;&amp;nbsp;being true,&lt;/DIV&gt;&lt;/LI&gt;&lt;LI&gt;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/skip-users-playback-to-next-track" target="_self"&gt;Skip To Next&lt;/A&gt;&amp;nbsp;may finish before&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/get-information-about-the-users-current-playback" target="_self"&gt;Get Playback State&lt;/A&gt; returns that&amp;nbsp;the new track is already playing.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;Such an API design is understandable as it increases API responsiveness and significantly reduces server load. However, it requires additional calls to the API to keep the application in sync with the player.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;My question is:&amp;nbsp;do I understand the behavior of the API correctly and do my ways of dealing with the described problems seem reasonable?&amp;nbsp;Have you ever encountered similar issues yourself?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks in advance!&lt;/P&gt;&lt;P&gt;Piotr&lt;/P&gt;</description>
    <pubDate>Wed, 12 Jul 2023 15:32:11 GMT</pubDate>
    <dc:creator>artbookspirit</dc:creator>
    <dc:date>2023-07-12T15:32:11Z</dc:date>
    <item>
      <title>Waiting for Web API commands with side-effects to complete</title>
      <link>https://community.spotify.com/t5/Spotify-for-Developers/Waiting-for-Web-API-commands-with-side-effects-to-complete/m-p/5608560#M9961</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;using the Web API, I noticed that requests to commands with side effects end earlier than the related changes appear. For example, if we call the endpoint&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/get-queue" target="_self"&gt;Get the User's Queue&lt;/A&gt;&amp;nbsp;immediately after&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/add-to-queue" target="_self"&gt;Add Item to Playback Queue&lt;/A&gt;, we'll sometimes get&amp;nbsp;the state of the queue, in which our item is not yet present.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Consequently, to get the contents of the queue after the addition has fully processed, I have to poll in a loop (with possible backoffs), calling&amp;nbsp;&lt;FONT face="courier new,courier"&gt;/me/player/queue&lt;/FONT&gt; &amp;nbsp;until my element's uri comes up in the output (which is of course an arbitrary heuristic).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It seems that many endpoints exhibit this "non-blocking" behavior, returning a &lt;FONT face="courier new,courier"&gt;2XX&lt;/FONT&gt; status code as soon as the action has been accepted for execution, for example:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/pause-a-users-playback" target="_self"&gt;Pause Playback&lt;/A&gt;&amp;nbsp;sometimes returns before a call to&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/get-information-about-the-users-current-playback" target="_self"&gt;Get Playback State&lt;/A&gt;&amp;nbsp;shows the&amp;nbsp;&lt;FONT face="courier new,courier"&gt;is_playing&lt;/FONT&gt;&lt;SPAN&gt; property as false,&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;DIV&gt;similarly&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/start-a-users-playback" target="_self"&gt;Start/Resume Playback&lt;/A&gt;&amp;nbsp;for&amp;nbsp;&lt;FONT face="courier new,courier"&gt;is_playing&lt;/FONT&gt;&amp;nbsp;being true,&lt;/DIV&gt;&lt;/LI&gt;&lt;LI&gt;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/skip-users-playback-to-next-track" target="_self"&gt;Skip To Next&lt;/A&gt;&amp;nbsp;may finish before&amp;nbsp;&lt;A href="https://developer.spotify.com/documentation/web-api/reference/get-information-about-the-users-current-playback" target="_self"&gt;Get Playback State&lt;/A&gt; returns that&amp;nbsp;the new track is already playing.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;Such an API design is understandable as it increases API responsiveness and significantly reduces server load. However, it requires additional calls to the API to keep the application in sync with the player.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;My question is:&amp;nbsp;do I understand the behavior of the API correctly and do my ways of dealing with the described problems seem reasonable?&amp;nbsp;Have you ever encountered similar issues yourself?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks in advance!&lt;/P&gt;&lt;P&gt;Piotr&lt;/P&gt;</description>
      <pubDate>Wed, 12 Jul 2023 15:32:11 GMT</pubDate>
      <guid>https://community.spotify.com/t5/Spotify-for-Developers/Waiting-for-Web-API-commands-with-side-effects-to-complete/m-p/5608560#M9961</guid>
      <dc:creator>artbookspirit</dc:creator>
      <dc:date>2023-07-12T15:32:11Z</dc:date>
    </item>
  </channel>
</rss>

