Tworzę API do korzystania (na razie) z klientów mobilnych Android i iOS. Główna aplikacja to rodzaj e-sklepu.
mam news punkt końcowy, rozważmy na przykład główny adres URL to http://consumer.com/api/v0/
Obecnie mam takie punkty końcowe do filtrowania newsów /news?actual=1&moderation=1 ....
Prosta tablica GET argumenty, ale mam kilka pytań na ten temat. Złą rzeczą (tak mi się wydaje) jest to, że parametry filtra (actual,moderation) są takie same jak nazwy kolumn w bazie danych.
- Czy wystawianie prawdziwych nazw kolumn to zły pomysł?
- Jak mogę rozwiązać problem? Mam jeden pomysł na wprowadzenie jakiegoś oprogramowania pośredniczącego (tak czy inaczej jest to możliwe, ale wykorzystuję lumen to duża możliwość), które przetłumaczy na przykład fałszywe nazwy
filter_actualifilter_mooderationdo prawdziwych nazw tabel, to nie zakłóci teraz mojej aplikacji, wystarczy dodać jeszcze jedną warstwę (moc oprogramowania pośredniego). Lub jest inny sposób na zrobienie tego.
Ale główny problem polega na tym, że jeśli muszę wykonać złożone zapytanie, rozważ następny przykład.
Stół news ma kolumnę company_id, company tabela ma kolumnę blocked, ta kolumna opisuje, czy firma jest zablokowana, czy nie.
Muszę uzyskać wszystkie wiadomości od firm, które nie są zablokowane, wykonałem coś takiego jak to pseudo zapytanie SELECT * FROM news WHERE company_id IN (SELECT id FROM companies WHERE blocked=0) (Nie sprawdziłem, ale mam nadzieję, że masz pomysł)
Jak stworzyć filtr punktów końcowych dla tego typu zapytania, teraz wprowadziłem dodatkowe opcje, takie jak non_blocked_companies i przepuszczaj następnie z innymi filtrami /news?actual=1&moderation=1&non_blocked_companies=1 a potem sprawdź, czy ten parametr został przekazany z innymi, więc w kodzie może to wkrótce wyglądać jak dużo if wyrażenia specyficzne dla każdego złożonego zapytania.
Myślałem o takich zapytaniach /news?actual=1&moderation=1&blocked[companies:company_id]=0 Myślę, że to jasne. używam pola z innej tabeli (companies) kolumna w news stół (company_id), który przechowuje identyfikator firmy.
Ale dla mnie to wygląda brzydko, bo tak jestdość złożone zapytanie w żądaniu get, ale główną złą stroną tego dla mnie jest to, że muszę dokładnie znać nazwę tabeli, kolumny tabeli, to nie jest teraz problem, ponieważ ten interfejs API jest używany tylko do komunikacji z klientami mobilnymi i nie będzie być otwarte publicznie, ale i tak chcę tworzyć niezawodne API
- Czy to zły pomysł, jak opisałem wcześniej?
- Jak mogę zorganizować moje API, aby było elastyczne (zmiany w API powinny w jak najmniejszym stopniu wpływać na frontend)
Bardziej zaawansowani programiści API proszę sugerować jaki jest najlepszy wybór w moim przypadku.
Dzięki.
Odpowiedzi:
1 dla odpowiedzi № 1Czy wystawianie prawdziwych nazw kolumn to zły pomysł?
Czy to nie jest zły pomysł.Deweloper będzie dobrze wiedział, co się dokładnie dzieje. Nazwałbym raczej bezpośrednią nazwę kolumny. Istnieje wiele API z Amazon i Google robi to samo.
Jak mogę rozwiązać problem?Mam jeden pomysł na wprowadzenie jakiegoś oprogramowania pośredniczącego (tak czy inaczej jest to możliwe, ale używam lumen to duża możliwość), które przetłumaczy niektóre fałszywe nazwy, na przykład filter_actual i filter_mooderation na prawdziwe nazwy tabel, to nie zepsuje teraz mojej aplikacji, po prostu dodaj jeszcze jedna warstwa (moc oprogramowania pośredniego). Lub jest inny sposób na zrobienie tego.
Wiele razy programista nie lubi wysyłać treści Uzyskaj odpowiedź, ale jeśli uważasz, że będzie to bardziej złożone i zepsuje aplikację. Sugeruję to zrobić. Oto szczegółowa dyskusja przed wykonaniem telefonu HTTP GET z treścią żądania
Możesz dodać wiele walidacji, aby wzmocnić interfejs API i obsługiwać różne scenariusze żądań.