API design advice request 

Thinking about designing an i18n-aware REST api for certain objects where `/object/:id` could have multiple translations. GETting the desired translation via Accept-Language is straightforward. For POSTind and PUTting things, I'm thinking about doing a separate sub-endpoint:

/object/:id/meta/:lang

So when I want to add or update a translation of an object, I would PUT at /object/:id/meta/uk, for instance.

This way I can refer to individual translations separately.

Follow

API design advice request 

The essence of the object is language-independent; the translated parts are descriptive - that's why I call the sub-endpoint `meta` in this example.

In the DB, the translations will most likely be in a separate table with one row per language per object.

What do y'all think?

· · Web · 1 · 0 · 0

API design advice request 

(And, surely, /objects/ should have been in plural all along).

Show thread
Sign in to participate in the conversation
La Quadrature du Net - Mastodon - Media Fédéré

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!