search

vrchatapi / specification

⚙️ VRChat API OpenAPI specification defining the API in a machine-readable format. This is then used for automatic generation of language-specific SDK's
MIT License
46 stars 32 forks source link

Document Notification API V2 #202

Open Foorack opened 1 year ago

Foorack commented 1 year ago

Old API: /auth/user/notifications

New API: /notifications

Objects and everything are COMPLETELY different. This is a complete rewrite.

Foorack commented 1 year ago

/notifications//respond

Foorack commented 1 year ago

Both V1 and V2 share not_ prefix, but are stored in completely separate tables/collections. They are not interchangeable.

Rexios80 commented 1 year ago

Is there a new websocket endpoint as well?

Foorack commented 1 year ago

@Rexios80 No but it sends new kinds of objects down the websocket IIRC :-)

Rexios80 commented 1 year ago

Are there equivalent objects just with different type strings?

Foorack commented 1 year ago

What? The Notification objects are completely different. In the Websocket it is indentified by a different type.

Rexios80 commented 1 year ago

I meant equivalent as in they represent the same event. The answer should be yes.

Rexios80 commented 1 year ago

So if I understood it correctly... only the group events are new in the websocket? Everything else is the same?

Rexios80 commented 1 year ago

How do we want to handle this? I see a few options:

  1. Rename the old APIs

    • Old notification APIs become: OldNotificaiton, OldNotificationsApi, etc.
    • New notification APIs are Notification, NoficationsApi, etc.

  2. Name the new notifications APIs something else

    • Old notification APIs remain unchanged
    • New notification APIs are NotificationV2, NotificationsApiV2, etc.

  3. Remove any references to the old APIs and name the new ones the same

If we do decide to keep the old notification APIs around, should we deprecate them?

SGA-max-faxalv commented 1 year ago

Huh? Just because there is a V2 doesn't mean V1 is deprecated.

Notifications from both V1 and V2 share namespace (a.k.a not_), but a not_ from V1 must be sent to the V1 endpoint, and a V2 notification to a V2 endpoint. VRChat will likely run both in parallel for a very long time, so we definitively need to support both.