W jakim celu dodawać osobno API?

Zielona szkoła
1

Pewnie Wam to pytanie wyda się śmieszne, ale …

Mam w tej chwili apkę, która działa w trybie “normalnym” :smile: oraz wyświetla dane m.in. w formacie JSON. np.:

  def show
    respond_to do |format|
      format.html 
      format.json { render json: @product, root: false }
    end
  end

Umożliwia także wyświetlenie tych danych gdy nie jesteśmy zalogowani lecz podamy w linii wywołania dodatkowe parametry takie jak email i user_token np.:
http://localhost:3000/products/234.json?user_email=moj@adres.com&user_token=cTdLcG

lub z konsoli:

export TOKEN=cTdLcG
export EMAIL=moj@adres.com
export ROOT_URL=http://localhost:3000

curl -i -H "Accept: application/json" -H "Content-type: application/json"  -H "X-User-Email: $EMAIL" -H "X-User-Token: $TOKEN" -X GET $ROOT_URL/products/234.json

Może mi ktoś wyjaśnić dlaczego dobrym pomysłem jest zbudowanie trochę odseparowanego API
app/api/v1/…?
Czy tylko po to, by zamiast wywoływać:
http://localhost:3000/products/234.json?user_email=moj@adres.com&user_token=cTdLcG
po zbudowaniu tego API móc wywołać:
http://localhost:3000/api/v1/products/234.json?user_email=moj@adres.com&user_token=cTdLcG
?

Co winno mnie skłonić do budowania wewnątrz app/controllers/api/v1/ prawie tych samych kontrolerów?

2

Chodzi o to, żeby zachowywać wersję spójną dla klientów. Zauważ, że jakby jakiś framework (typu React czy Angular) używał Twojego API to podczas zmian w budowie zachodziłyby konflikty, co rodziłoby problemy w komunikacji pomiędzy aplikacjami. Chyba, że dev aplikacji klienckiej na żywo, razem z Tobą wprowadzał uaktualnienia, no ale co w wypadku jeśli tych klientów jest kilka, kilkanaście czy kilkadziesiąt.

EDIT: Jeśli nie używasz widoków, które korzystają z JSONa to nie powinieneś uwzględniać tego w kontrolerach.

3

OK, wersjonowanie API (v1, v2…) ma niewątpliwie zaletę.
Co jeszcze winno mnie skłaniać do tego, by to odseparowywać?

Czy w ogóle należy (pytanie do praktyków) pisać osobną aplikację i mieć dwa projekty
http://moja_apk.com oraz
http://api.moja_apka.com ?

Czy mieć to w jednej aplikacji z rozbiciem na app/controllers i app/controllers/api/v1 …v2 ?

Chodzi mi o kwestie, którą zapewne @michalg miał na myśli, czyli aby np. zmiany w modelach nie rzutowały na działanie API.

Podpowiedzcie proszę, jak najlepiej (najpoprawniej) to zorganizować?

4

Z tego co napisałeś, to zdaje się, że cały Twój problem rozwiąże dopisanie jednego wiersza do routes.

5

Nie bardzo zrozumiałem, o jaki wpis chodzi.
Bo taki wpis:

  namespace :api, defaults: { format: :json } do
    namespace :v1 do
      devise_scope :user do
        post 'sessions' => 'sessions#create', :as => 'login'
        delete 'sessions' => 'sessions#destroy', :as => 'logout'
      end
      .....
    end
  end

… to ja już mam.

Liczyłem, że bardziej doświadczeni developerzy podzielą się swoimi refleksjami typu:
“Nie twórz wspólnego ‘makaroni’. Rób tylko w osobnych projekach, gdyż …” lub na jakieś sugestie dotyczące tego, jaki architektonicznie zarys to powinno mieć, ale cóż … :frowning:

6

Obejrzyj sobie https://www.youtube.com/watch?v=FpS_E90-6O8 (youtube pozniej Ci zasugeruje sporo podobnych), a pozniej poczytaj posty Steve na temat API/REST i wersjonowania i czy warto.

Nielatwe tematy. Mocno zalezne od kontekstu projektu. Nie ma zlych rozwiazan.

7

Chciałem powiedzieć, że dopóki nie masz konkretów, to nie mnożysz na zapas bytów (np. owych kontrolerów), a jedynie, jeśli istototnie jest taki wymóg, zapewniasz obsługę owej ścieżki stosownym wpisem w routes.