Prodej módní značky DANNYS clothing
Zobrazují se odpovědi 1 až 2 z 2

Endpointy v API pro CRM projekt

  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.

  2. Co se právě děje na Webtrhu?
  3. 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é.

Hostujeme u Server powered by TELE3