Zalozmy ze dostajecie zadanie zrobic klienta restowego. W pracy dostajecie wytyczne jak maja wygladac endpointy czy sie musicie dogadac z frontendowcem? W obu przypadkach koniec koncow dostajecie informacje o endpointach. Jak ta informacja wyglada? Obrazek, tabelka, robione w jakims programie?
@Bruno_: To się nazywa kontrakt i ustala się między frontem a backendem, chyba, że to API publiczne, to backend sam decyduje, bo klient api jest nieznany.
Jak ta informacja wyglada?
Najlepiej, jak to jest po prostu dokumentacja API, czyli masz zdefiniowaną strukturę requestu i response'u. Jest teraz do tego sporo toolsów wspomagających cały proces tworzenia API, na przykład chyba jeden z popularniejszych Swagger, którego sam zacząłem używać przy obecnym projekcie.
@zakopiak: podoba mi sie ten swagger, jak robisz swoj projekt to w jakiej kolejnosci? najpierw programujesz potem swaggera uzupelniasz, odwrotnie czy oba na raz w miare jak projekt rosnie?
@Bruno_: Daleś #java to tam się robi tak, że na etapie programowania adnotacjami ze Spring Foxa sobie adnotujesz metody i później na podstawie tego automatycznie generuje ci się dokumentacja ze swaggera
@Bruno_: A w #javascript np jak używasz nest.js to też jest biblioteka do tego, że dekoratorami w typescripcie oznaczasz sobie metody i od razu masz gotową dokumentację
@Bruno_: Przeważnie najpierw kontrakt (dokumentacja API), potem implementacja.
Ja robię API pod aplikację mobilną do istniejącego projektu, wiec robię to inkrementacyjnie metoda po metodzie, ale najpierw kontrakt uzgadniam z zespołem od appek ios/androida, a potem implementacja. Przy czym u mnie implementacja to nie pisanie od zera, tylko dostarczenie istniejącej logiki biznesowej w postaci tego API.
Jak zaczynasz produkt od zera to dochodzi w ogóle zaprojektowanie tej logiki biznesowej.
@Bruno_: tylko pamietaj zeby miec na uwadze sensownosc prosb. frontendowcy czesto nie wiedza jak budowac poprawnie API a w szczegolnosci nie sa swiadomi kosztownosci zapytan, wiec beda prosic o duzo.
ja to robie tak, ze przegladam jakie sa wymagania wobec frontu, projektuje API tak aby bylo spojne z reszta i jak najbardziej wydajne i wtedy jako propozycje daje frontendowi.
Zalozmy ze dostajecie zadanie zrobic klienta restowego. W pracy dostajecie wytyczne jak maja wygladac endpointy czy sie musicie dogadac z frontendowcem?
W obu przypadkach koniec koncow dostajecie informacje o endpointach. Jak ta informacja wyglada? Obrazek, tabelka, robione w jakims programie?
Najlepiej, jak to jest po prostu dokumentacja API, czyli masz zdefiniowaną strukturę requestu i response'u.
Jest teraz do tego sporo toolsów wspomagających cały proces tworzenia API, na przykład chyba jeden z popularniejszych Swagger, którego sam zacząłem używać przy obecnym projekcie.
najpierw programujesz potem swaggera uzupelniasz, odwrotnie czy oba na raz w miare jak projekt rosnie?
Ja robię API pod aplikację mobilną do istniejącego projektu, wiec robię to inkrementacyjnie metoda po metodzie, ale najpierw kontrakt uzgadniam z zespołem od appek ios/androida, a potem implementacja. Przy czym u mnie implementacja to nie pisanie od zera, tylko dostarczenie istniejącej logiki biznesowej w postaci tego API.
Jak zaczynasz produkt od zera to dochodzi w ogóle zaprojektowanie tej logiki biznesowej.
Robiąc najpierw dokumentację z kolei Swagger potrafi wygenerować całkiem spoko szkielet projektu w dowolnym języku.
ja to robie tak, ze przegladam jakie sa wymagania wobec frontu, projektuje API tak aby bylo spojne z reszta i jak najbardziej wydajne i wtedy jako propozycje daje frontendowi.