Closing the loop on this, I just landed [1] a change to the device service
so the need for headers is gone, and all the routes are contextual to a
device selected in /devices, per Sam's request.

Thanks Sam!

Eli Perelman

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1229084

On Thu, Nov 26, 2015 at 10:45 AM, Eli Perelman <[email protected]>
wrote:

> Hey Sam,
>
> That was a conscious decision we made because referring to a particular
> device could be more than just a serial number, it could also need a remote
> host and port.
>
> The other option would be to make :id a reference to a device not directly
> by serial number. Right now we store a reference to a device session via a
> hash which is returned via a response header, we could potentially make
> that session identifier the ID used in the URL, and then the other methods
> could map to that interface.
>
> I will agree with you that your proposal is more RESTy. Feel free to file
> a bug and I'll look into it.
>
> Thanks!
>
> Eli Perelman
>
>
>
> On Thu, Nov 26, 2015 at 10:36 AM, Sam Giles <[email protected]> wrote:
>
>> Hey
>>
>> I was taking a look at the fxos-device-service to see if I could easily
>> add B2GDroid support and thought the method of requesting a command to
>> apply to a specific device was odd.
>>
>> The API has the concept of `/devices` which will give you a collection of
>> the attached devices identified by their adb ids.  You can then get a
>> particular device by getting `/devices/:id`.
>>
>> Following that, the other commands don't seem to relate to the adb device
>> id - and I *just* spotted: unless you use a header.
>>
>> Wouldn't using the device ID in the URL give us more transparent URLs by
>> basing the URLs on the resources and related actions the consumer wants to
>> perform?
>>
>> For example:
>>
>> POST /devices/:id/restart
>> GET /devices/:id/logs
>> GET /devices/:id/properties
>> etc.
>>
>> Sam
>>
>>
>
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos

Reply via email to