Modelowanie REST API systemu ogłoszeń

0

Cześć. Załóżmy że mamy portal z jakimiś ogłoszeniami, np. typu OLX. Mamy tam wiele kategorii, np. Motoryzacja, Nieruchomości czy też Elektronika.
Każda z tych kategorii ma jakieś podkategorie, np. Motoryzacja ma powiedzmy Motocykle i Samochody a te podkategorie mają różne parametry.
Jak modeluje się RESTowe API do zapisu takich ogłoszeń? Wydaje mi się że nie strzela się na setki różnych endpointów w zależności od podkategorii danej podkategorii jakiejś kategorii. Zaimplementowałem więc sobie coś takiego na interfejsach ale to też nie ma prawda działać bo nie da się zrobić deserializacji kiedy nie wiadomo jakiego typu jest implementacja. Ktoś ma doświadczenie w tym i może coś polecić?

0

Robisz POST'a pod /offers i tyle. Reszta leci w body (category_id, subcategory_id).

0
Desu napisał(a):

Robisz POST'a pod /offers i tyle. Reszta leci w body (category_id, subcategory_id).

Owszem tylko teraz jeśli mam po stronie backendu np. Springa to muszę utworzyć jakąś klasę DTO na którą ten JSON będzie deserializowany, przykład:
https://spring.io/guides/tutorials/bookmarks/#_http_is_the_platform
Owszem taka klasa może mieć wszystkie możliwe pola i najwyżej część z nich będzie null'em ale jest to kompletnie bezsensu.
Stąd też moje pytanie bo robienie wielu endpointów dla każdej możliwości też wydaje mi się bezsensu...

Chyba że to nie modelowanie klas do deserializacji i sam rest jest problemem tylko Spring który tak to robi.

0

nie wiem jak Spring, ale jezeli bedziesz miec w DTO tylko rzeczy ktore chcesz by zdeserializowal, to on tylko je zdeserializuje a reszte pominie. Wiec w DTO w backendzie bedziesz miec tylko te wartosci ktore potrzebujesz

Jezeli sie tak nie da to zrob pelne DTO a pozniej zrob klase biznesowa z tylko tymi polami ktore potrzebujesz i uzyj jakiegos Mappera by Ci to zmapowal (ewentualnie mozesz uzyc cos na zasadzie https://marketplace.visualstudio.com/items?itemName=54748ff9-45fc-43c2-8ec5-cf7912bc3b84.mappinggenerator tylko dla javy)

0
fasadin napisał(a):

nie wiem jak Spring, ale jezeli bedziesz miec w DTO tylko rzeczy ktore chcesz by zdeserializowal, to on tylko je zdeserializuje a reszte pominie. Wiec w DTO w backendzie bedziesz miec tylko te wartosci ktore potrzebujesz

Owszem, masz rację. Mogę tak zrobić ale wówczas na każdą podkategorie potrzebny jest osobny endpoint ponieważ produkt z każdej kategorii zawiera inne pola.

Jezeli sie tak nie da to zrob pelne DTO a pozniej zrob klase biznesowa z tylko tymi polami ktore potrzebujesz

Też o tym myślałem i jest to jakieś rozwiązanie ale jakoś nie chce mi się wierzyć że takie allegro, olx czy inne tego typu mają potężnego DTOsa który zawiera wszystkie możliwe pola z każdej kategorii a potem tylko wysyłają to co potrzebują... Jakoś wydaje mi się to być bezsensu.

0

podaj przyklad obszerniejszy. Bo cos mi sie wydaje, ze Cie nie rozumiem

0

Mamy produkty różnych kategorii i każdy z nich ma charakterystyczne właściwości, np.
Samochód:

  • pojemność silnika,
  • rok produkcji
  • przebieg
    itd itd

Mieszkanie:

  • metraż
  • które piętro
  • liczba pokoi
    itd itd

Jedno i drugie to oferta w rozumieniu ogłoszenia ale każde z nich ma inne właściwości.
Mogę więc zrobić sobie post request na adres api.com/offers przekazując JSONa z ofertą np. samochodu więc będzie tam pojemność, przebieg itp ale po stronie serwera muszę teraz to na coś deserializować. Piszę w Kotlinie i korzystam Springa więc mam coś takiego:

    @PostMapping("/offers")
    fun saveOffer(@RequestBody offer: CarDto) {
        repository.save(offer)
    }

W powyższym przykładzie body (czyli JSON samochodu) musi być na coś deserializowany więc mam CarDto który jest DTO. I to jest okej natomiast na ten sam endpoint nie mogę już wysłać oferty mieszkania. Chciałbym więc to zrobić bardziej abstrakcyjnie, tzn wydaje mi się że tak będzie dużo lepiej. Chciałbym więc dodać endpoint api.com/offers i móc na ten adres wysyłać jakiejkolwiek ogłoszenie - samochody, mieszkania, elektronikę itp itd ale po stronie servera na coś trzeba to deserializować i tu jest problem.
Na początku pomyślałem że problem leży w projektowaniu restowego API ale jak tak piszę to wszystko to zaczynam zastanawiać się czy to nie jest po prostu problem tego w jaki sposób Spring pozwala tworzyć endpointy.

3

Każdy Atrybut ma Nazwę i Typ, każda Kategoria ma określoną listę Atrybutów. Każdy Produkt należy do Kategorii oraz ma listę Atrybutów, które poza Nazwą i Typem mają też Wartość.
Nie trzeba więcej niż jednego endpointa, bo czy to samochód czy mieszanie jest tylko Produktem z kolekcją Atrybutów.

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