Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 25 of 25
  1. #21
    Senior Member
    Join Date
    Aug 2014
    Location
    UK
    Posts
    532
    Quote Originally Posted by mherger View Post
    > I presume there is no way around this and I can do nothing about it?

    Ouch... that's a big issue indeed. You could of course work on a PR to
    add PUT/DELETE... but that would require any user of your plugin to run
    the latest LMS.
    Ok, as there is probably no reason now why they can't be allowed, I'll submit a PR. I'll see if its straight forward enough to let them through only to the "rawfunction" hook, to eliminate negating any reason those HTTP verbs were excluded in the first place.

    I may as well carry on, as I've got this far.

    I'll probably add an additional deeper route on the POST method that replicates the same operation for unsupported HTTP verbs, so that it can be supported on older versions e.g. POST /api/Players/{playerid}/queue/delete as a duplicate of DELETE /api/Players/{playerid}/queue

  2. #22
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,302
    Are you getting close to implementing /players/{playerid}/song ?
    What would it return, just the song or also album/artist info ?
    I guess Iíd have to call /players/{playerid}/play-status to see if itís actually playing, or would this be part of /players/{playerid}/song result ?

    Iím asking because the normal status query result is on the big side for the low memory Arduino based status display Iím experimenting with. I was about to implement a proxy that strips of the part of status result Iím not interested in but thought Iíd ask if you are close to implementing something similar first.

    My preliminary plan is to display, artist, album and title of currently playing song when something is playing.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets
    Starting with LMS 8.0 I no longer support my plugins/applets (see here for more information )

  3. #23
    Senior Member philchillbill's Avatar
    Join Date
    Jan 2019
    Location
    The Netherlands
    Posts
    817
    Quote Originally Posted by expectingtofly;
    I'll probably add an additional deeper route on the POST method that replicates the same operation for unsupported HTTP verbs, so that it can be supported on older versions e.g. POST /api/Players/{playerid}/queue/delete as a duplicate of DELETE /api/Players/{playerid}/queue
    Remember this:

    Quote Originally Posted by expectingtofly;
    No, really, its essential. Its not a question of bending the rules. It needs to use the correct HTTP verb for the operation that you want on the resource, otherwise it just doesn't work.
    I guess 'essential' is an elastic concept

  4. #24
    Senior Member
    Join Date
    Aug 2014
    Location
    UK
    Posts
    532
    Quote Originally Posted by philchillbill View Post
    Remember this:



    I guess 'essential' is an elastic concept
    Looks like I chose the wrong word. But I think you know what I meant.

    I recall you wanted to be able to make all the calls from a browser, which is why you wanted all the API calls to use GET. You might find it useful that this API is using the standard openAPI specification method, which means you can just use the swagger tools in your browser to view the specification ( https://swagger.io/tools/swagger-editor/ ) paste in the openAPI yaml specification, and then amend the api url to your local LMS server. From there you will be able to browse the api specification, press "Try it out" on any call and call it right there from your browser, with all the parameters available from a clickable form :-)
    Last edited by expectingtofly; Today at 05:57.

  5. #25
    Senior Member
    Join Date
    Aug 2014
    Location
    UK
    Posts
    532
    Quote Originally Posted by erland View Post
    Are you getting close to implementing /players/{playerid}/song ?
    What would it return, just the song or also album/artist info ?
    I guess Iíd have to call /players/{playerid}/play-status to see if itís actually playing, or would this be part of /players/{playerid}/song result ?

    Iím asking because the normal status query result is on the big side for the low memory Arduino based status display Iím experimenting with. I was about to implement a proxy that strips of the part of status result Iím not interested in but thought Iíd ask if you are close to implementing something similar first.

    My preliminary plan is to display, artist, album and title of currently playing song when something is playing.
    Not got there yet, but, yes I am getting close, I'm currently working through the player queue operations, I'll be picking it up again in a few days. I'm going to go through specifying and standardising the responses at some point. But you are right, some thought needs to go into how atomic each operation is and strike the right balance between maintaining the meaning, and the usability. It will be useful to get feedback when I've got a preview version done.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •