Zwracanie listy kontrahentów w zależności od uprawnień

0

Cześć.
Siedze dalej nad api do wystawiania faktur i mam kolejne pytanie. Zeby wybrać kontahenta do faktury aplikacja kliencka wysle request do metody api zwracającej liste kontrahentow. Powiedzmy ze sa 3 uprawnienia "admin", "manager", "salesman".
użytkownik z uprawnieniem admin ma mieć dostęp do wszystkich kontrahentów
użytkownik manager ma mieć dostęp do kontrahentów tylko z przypisanych mu grup
użytkownik salesman ma mieć dostęp tylko do kontrahentów ze swojej grupy

Pytanie, czy mam zrobić 3 metody w API zwracające liste kontehentów?
Myślałem o czymś w stylu

[Route("[controller]")]
[ApiController]
public class KontrahenciController
{
  // ....
  [HttpGet]
  [Authorize(Role="admin")]
  public IActionResult GetAllForAdmin()
  {
    //...
    return listaKontrahentow.GetByUser(Users.Admin);
  }

    [HttpGet]
  [Authorize(Role="manager")]
  public IActionResult GetAllForManager()
  {
    //...
    return listaKontrahentow.GetByUser(Users.Manager);
  }

    [HttpGet]
  [Authorize(Role="user")]
  public IActionResult GetAllForSalesman()
  {
    //...
    return listaKontrahentow.GetByUser(Users.Salesman);
  }
}
1

API samo powinno rozpoznawać jaki rodzaj użytkownika pyta i zwracać odpowiednie zbiory danych.

1

@katakrowa: czyli mogło by być coś jak poniżej?

[Route("[controller]")]
[ApiController]
public class KontrahenciController
{
  // ....
  [HttpGet]
[Authorize]
  public IActionResult GetAll()
  {
    var typUzytkownika = // pobranie informacji kto to jest
    
    List<Kontrahent> Kontrahenci = null;
    switch(typUzytkownika)
    {
      case "admin":
      Kontrahenci = listaKontrahentow.GetByUser(Users.Admin);
      break;
      case "manager":
      Kontrahenci = listaKontrahentow.GetByUser(Users.Manager);
      break;
       case "salesman":
      Kontrahenci = listaKontrahentow.GetByUser(Users.Salesman);
      break;
    } 
    
    return Kontrahenci;
  }
2

No już bardziej bo użytkownik/klient API nie powinien musieć wiedzieć kim jest.

0

@katakrowa: a tak żeby było już całkiem dobrze to mniej więcej czego powinienem tu użyc?

1

Nie wiem co to za projekt ale jeśli ma być częścią większego działającego systemu to zdecydowanie użyłbym projektu tego systemu.
Jeśli jednak API do wystawiania faktur chcesz napisać metodą ad-hoc dopisując kolejne klocki (na czuja) nie mając wyraźnej koncepcji całości to bądź pewien, że i tak nic z tego nie wyjdzie.

0

Może rzeczywiście źle do tego podchodze. Jesteś w stanie dać mi jakiś przykład albo link jak powinno być zaprojektowane api?

2

API to tylko "wierzch" systemu. Nie pisze się API do czegoś co nie istnieje. Jeśli nie masz jeszcze oprogramowanych tych faktur to nie ma mowy o robieniu API.
Oczywiście możesz zaprojektować taki interfejs jako pewna abstrakcja faktury ale bez wyraźnej koncepcji co ma się z tym działo dalej będzie to trudne i dziwne.
Napisz może jaki jest faktyczny cel tego projektu. Czy to jest coś robione od podstaw czy może faktyczny element integracji działającego już systemu z aplikacjami zewnętrznymi.
Bardzo trudno doradzić "ogólnie" w swoim systemie mamy moduł faktur i muszę przyznać, ze jest to chyba jeden z najbardziej złożonych modułów.

Pomijając faktyczne systemy przed zaprojektowaniem API musisz wypisać wszystko co takie API musi obsługiwać, np.:

  • Tworzenie, modyfikacja, kasowanie faktur ( nagłówków ) ;
  • Tworzenie, modyfikacja, kasowanie pozycji faktur ( nagłówków ) ;
  • Przeliczanie faktur do konfiguracji ( od netto, od brutto, od waluty wyjściowej, w zależności od sposobu stosowanych zaookrągleń itp.. itd .. );
  • Faktury można korygować :-) Tu mamy kilka metod realizacji takich korekt ;
  • Baza kontrahentów ( czy wspólna, czy każdy ma swoją )
  • Uprawnienia do dokumentów, firm, oddziałów ( należy wyraźnie rozdzielić uprawnienia do danych od uprawnień do interfejsów/funkcjonalnośi )
  • jeśli wielowalutowość to skąd kursy ?
  • jeśli kontrahenci to może także zagraniczni a ci mają inne metody walidacji adresów, numerów podatkowych
  • faktura musi mieć wydruk a rodzajów faktur jest tyle, że głowa boli ( VAT, Vat-marża, bez VAT ) o wielojęzycznościach nie wspomnę.
  • faktury muszą mieć ciągłą numerację więc system musi jakoś wspomagać nadawanie numerów ( być może także obsługiwać zatykanie dziur w numeracji )
  • są różne sposoby płatności a także faktury zaliczkowe i rozliczające zaliczki, które zawsze są całymi ciągami dokumentów.
    generalnie przeje... itp... itd ... Jest tego dużo!

Samo zaprojektowanie takiego systemu fakturującego to już minimum kilka dni pracy projektowania bazy, potem klas, dopiero na samym końcu można myśleć o interfejsie API.
Dlatego jeśli nie podajesz wymagań to nie sposób cokolwiek sensownego doradzić.

2
katakrowa napisał(a):

API to tylko "wierzch" systemu. Nie pisze się API do czegoś co nie istnieje. Jeśli nie masz jeszcze oprogramowanych tych faktur to nie ma mowy o robieniu API.
(...)
Samo zaprojektowanie takiego systemu fakturującego to już minimum kilka dni pracy projektowania bazy, potem klas, dopiero na samym końcu można myśleć o interfejsie API.
Dlatego jeśli nie podajesz wymagań to nie sposób cokolwiek sensownego doradzić.

Większą patologią jest jednak zaczynanie od projektowania bazy danych. Najpierw zaczyna się od definiowania wymagań i funkcjonalności, w tym samym czasie wyklaruje się też model domenowy - dlaczego nie miałoby to być zrobione w formie API? Przecież nikt nie mówi, że takie API będzie ostateczne, poza tym w momencie ustabilizowania można równolegle robić front w oparciu o zmockowane API.

0

No dobra, ale api jest bezstanowe czyli nie moge liczyc ze gdzies tam trzymany jest dla mnie obiekt faktura i ja sobie przez api wywołuję np metodę klasy, np
mojaFaktura.DodajPozycje(Pozycja faktury);

Ja webapi rozumiem tak ze udostepnia ono endpoint np
http://mojeapi/faktura/dodaj
i do tego muszę przekazać np w request body cały obiekt faktury wraz z pozycjami tej faktury
następnie w metodzie kontrolera do któej trafił request będzie jakaś walidacja tego obiektu faktury który przesłałem
później jak wszystko bedzie ok to zostanie zapisane do bazy i mi jest zwracany komunikat ze faktura została dodana

0
kalimata napisał(a):

Ja webapi rozumiem tak ze udostepnia ono endpoint np
http://mojeapi/faktura/dodaj

Teraz piszesz o "Faktura/dodaj" a wątek zacząłeś od pobierania kontrahentów wg szczególnych uprawnień użytkownika. Jedno i drugie stawia Twój projekt w zupełnie innym świetle. Gdybyś zaczął od faktura/dodaj to bym Ci inaczej odpowiedział.

1

To o czym jest ten wątek?

Bo jak o zwracaniu listy kontrahentów, to to powinien być jeden endpoint, a decyzja o tym, którzy z nich powinni być zwróceni w zależności od typu użytkownika powinna się znajdować raczej gdzieś w logice biznesowej niż w kontrolerze. Dlaczego niby kontroler miałby podejmować taką decyzję?

0

@katakrowa: przepraszam ze tak mieszam, próbuje jakos zrozumiec temat i skojarzyłem ze skoro potrzebuje dodac nowa fakture to bede tez potrzebowal zwrocic liste kontrahentow z ktorych mozna wybrac własciwego.

@somekind chodziło mi o zwrocenie kontrahentow mozliwych do wyboru do faktury

0
kalimata napisał(a):

No dobra, ale api jest bezstanowe czyli nie moge liczyc ze gdzies tam trzymany jest dla mnie obiekt faktura i ja sobie przez api wywołuję np metodę klasy, np
mojaFaktura.DodajPozycje(Pozycja faktury);

O jakiej filozofii API mowa?
Takie funkcyjne (czy obiektowe) możliwe są w np SOAP, ale domniemujemy że chodzi o REST (nie padło to wyraźnie).
Nawiasem mówiąc projektując ściezkę endpoiintu
/faktury/7654/pozycje i w to wpadasz z POST/PUT masz ortodoksyjne dodawanie pozycji w REST.
Widzę że jesteś "nieco" w krzokach. Masz jakiś podkład teoretyczny o REST, czy "strzelasz probabilistycznie" ?

0
katakrowa napisał(a):

Nie wiem co to za projekt ale jeśli ma być częścią większego działającego systemu to zdecydowanie użyłbym projektu tego systemu.
Jeśli jednak API do wystawiania faktur chcesz napisać metodą ad-hoc dopisując kolejne klocki (na czuja) nie mając wyraźnej koncepcji całości to bądź pewien, że i tak nic z tego nie wyjdzie.

Popieram to pytanie.
Bo bez wypowiedzi, jakiego charakteru to projekt, nie da się wiele mądrego powiedzieć.

1 użytkowników online, w tym zalogowanych: 0, gości: 1