logo
27.07.2019 23:46
1
Ahoj,

dneska jsem se pustil do promysleni struktury API pro jedno mensi CRMko a potreboval bych nakopnout, co se tyka endpointu. V CRM je 90% vseho vazano na uzivatele. Kdyz si tedy predstavim, ze mam jakesi moduly: faktury, soubory, produkty, klienti, apod., tak je dobre aby endpointy byly takhle?

accounts/{user_id}/invoices
accounts/{user_id}/files
accounts/{user_id}/products
accounts/{user_id}/clients

Prijde mi to divne - vsechno bude zacinat accounts/. Ale kdyby to tak nebylo, tak zase musim user_id posilat jako GET parametr, a to se mi zda hloupa cesta.

Poradite prosim, jak tohle mate reseno vy?

Diky.
28.07.2019 01:26
2
Předpokládám, že API bude konzumovat nějaká aplikace, která bude mít nějaké uživatele a ti se budou muset vůči API nějak autorizovat/autentikovat. Potom jde o to zobrazit jim jejich data a ne data ostatních uživatelů. V takovém případě mi není jasné proč potřebujete mít jako součást těchto user-facing URL informaci o aktuálním uživateli. Tu přeci již budete mít, třeba v JWT tokenu. Stačilo by pouze:

/invoices
/files
/products
/clients

+ všechny možné endpointy kolem toho. Pokud by si potom chtěl uživatel A zobrazit faktury uživatele B, musel by mu je buďto vyfakturovat nebo být fakturován (či být v jiném vztahu) a to by mi dávalo větší smysl získat přes filtraci pomocí GET parametrů ve stylu /invoices?from={id}

Ty endpointy co jste vypsal, mi připadají spíše jakoby měly sloužit pro nějaké administrační rozhraní pro nějakého superživatele nebo pro případ, kdy se konzumenti API neautorizují/neautentikují, ale i to by šlo vyřešit pomocí prvního schématu co jsem vypsal. Potom, a když už, tak při zachování stejné struktury:

/user/{id}/invoices
/user/{id}/files
/user/{id}/products
/user/{id}/clients

je kratší a významově stejné.