feat: new endpoint /instances/recent

[Hackebein]

Adds:
GET https://vrchat.com/api/1/instances/recent

[ariesclark]

accepts paging. ie: n=100.

[Hackebein]

accepts paging. ie: n=100.

offset is supported too. added both

[VinyarionHyarmendacil]

This reminds me that the spec doesn't really differentiate between the InstanceID per se (everything after the :) and a LocationID (the WorldID:InstanceID), but is it even worth clarifying at this point (for anything past or future)?

[Hackebein]

This reminds me that the spec doesn't really differentiate between the InstanceID per se (everything after the :) and a LocationID (the WorldID:InstanceID), but is it even worth clarifying at this point (for anything past or future)?

Do we know that the current naming is correct?

I would expect to get an array of instances or array of instance ids from an endpoined named instances/recent.

[VinyarionHyarmendacil]

This reminds me that the spec doesn't really differentiate between the InstanceID per se (everything after the :) and a LocationID (the WorldID:InstanceID), but is it even worth clarifying at this point (for anything past or future)?

Do we know that the current naming is correct?

I would expect to get an array of instances or array of instance ids from an endpoined named instances/recent.

Well, take Instance.yaml itself for instance:

...
properties:
...
  id:
    $ref: ./InstanceID.yaml
  instanceId:
    type: string
    minLength: 1
    example: 12345~hidden(usr_c1644b5b-3ca4-45b4-97c6-a2a0de70d469)~region(eu)~nonce(27e8414a-59a0-4f3d-af1f-f27557eb49a2)
...
  location:
    $ref: ./InstanceID.yaml
...
  worldId:
    $ref: ./WorldID.yaml
...

And User.yaml:

...
properties:
...
  id:
    $ref: ./UserID.yaml
  instanceId:
    $ref: ./InstanceID.yaml
...
  location:
    $ref: ./WorldID.yaml
...
  worldId:
    $ref: ./WorldID.yaml
...

And GET https://vrchat.com/api/1/instances/wrld_00000000-0000-0000-0000-000000000000:81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use) returns:

{
...
  "id": "wrld_00000000-0000-0000-0000-000000000000:81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use)",
  "instanceId": "81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use)",
...
  "location": "wrld_00000000-0000-0000-0000-000000000000:81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use)",
...
  "worldId": "wrld_00000000-0000-0000-0000-000000000000"
}

but GET https://vrchat.com/api/1/users/usr_00000000-0000-0000-0000-000000000000 returns:

...
  "id": "usr_00000000-0000-0000-0000-000000000000",
  "instanceId": "81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use)",
...
  "location": "wrld_00000000-0000-0000-0000-000000000000:81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use)",
...
  "worldId": "wrld_00000000-0000-0000-0000-000000000000"

all the while InstanceID.yaml itself says:

...
example: '12345~hidden(usr_c1644b5b-3ca4-45b4-97c6-a2a0de70d469)~region(eu)~nonce(27e8414a-59a0-4f3d-af1f-f27557eb49a2)'
...

which indicates to me that the InstanceID proper is just the stuff after the colon, and the whole thing WorldID:InstanceID ought to be called a LocationID, considering the API is consistent about the fields with "location" in the name

[ariesclark]

Hm, I'd be okay with naming them Locations.

[ariesclark]

Can you create a follow-up PR, updating any place that might incorrectly reference InstanceIDs in favour of the new LocationID?

[Hackebein]

This reminds me that the spec doesn't really differentiate between the InstanceID per se (everything after the :) and a LocationID (the WorldID:InstanceID), but is it even worth clarifying at this point (for anything past or future)?

Do we know that the current naming is correct?
I would expect to get an array of instances or array of instance ids from an endpoined named instances/recent.

Well, take Instance.yaml itself for instance: [...]
And User.yaml [...]
And GET https://vrchat.com/api/1/instances/wrld_00000000-0000-0000-0000-000000000000:81645~friends(usr_00000000-0000-0000-0000-000000000000)~region(use) [...]

which indicates to me that the InstanceID proper is just the stuff after the colon, and the whole thing WorldID:InstanceID ought to be called a LocationID, considering the API is consistent about the fields with "location" in the name

I updated all references related to WorldID/InstanceID/LocationID. It doesn't line up everywhere with what VRChat is sending. in some cases "world" is used, while the response contains a location. My inital "InstanceID" naming was therefore even less fitting.