Czy w API zachować te same reguły routingu?

0

Przymierzamy się powoli do jakiegoś API dla 4programmers.net. W związku z tym pytanie, co myślicie: Czy URL w API powinny wyglądać tak samo jak URL w części webowej?

URL na 4programmers.net wyglądają jak wyglądają ze względów - powiedzmy - "historycznych". Tzn. pierwsza litera w segmencie jest pisana wielką litera. I tak mamy np. /Mikroblogi czy /Praca, czy /Login. Jak można zauważyć, część jest pisana w wersji PL a część w EN (ze względów SEO oczywiście). Dla ułatwienia możemy zrobić, że adres api.4programmers.net/Mikroblogi będzie zwracała listę wpisów w JSON. Możemy jednak porzucić tę konwencję w API i stosować linki w wersji EN (małymi literami), czyli: api.4programmers.net/microblogs.

Co o tym myślicie? Wydaje mi się ze ta druga opcja?

2

Obstawiałbym za jedną wersją, i najlepiej jednojęzyczną. Konwencja wielkich liter do mnie nie przemawia, i jestem za tym drugim rozwiązaniem.

0

Mnie osobiście wszystko jedno, która koncepcja, byle była "spójna wewnętrznie", jak pisze @Hispano-Suiza. Mogą być litery wielkie i małe, po polsku i po angielsku. Jednak jest jeszcze, jak ja to mógłbym nazwać, "spójność zewnętrzna": czy zależy nam na tym, żeby API forum podążało za jakimś trendem w budowaniu API (jeśli w tym są jakieś trendy)? Może większość API takich for jak to jest po angielsku małymi literami (nie sprawdzałem), i chcemy też tak mieć?

Jakby co, to ja się właśnie uczę OpenAPI. Fajne to, wydaje się takie przemyślane. :)

PS. @Adam Boduch, a są jakieś specjalne powody, dla których zabrałeś się za tworzenie API? Może one implikują użycie jakiejś konwencji.

0

Z jednej strony zawsze byłem za prostym, anglojęzycznym, małoliterowym™ (lowercase) stylem (spotykałem kwiatki typu getLudzie, brr), jednakże jeśli na stronie są Mikroblogi, a w API ma być microblogs, to w oczy kłuje spójność (a raczej jej brak).. szczególnie, że obok będzie Login i login, dlatego nie jestem jakoś święcie przekonany, że microblogs byłoby tu lepsze.

1

Aktualne API:

  • Zwraca HTML'a który ma ładnie wyglądać
  • Raczej nie będzie wykorzystywany przez klientów innych niż przeglądarka
  • Markup będzie się zmieniał żeby odpowiadać walorom estetyki, UI

Nowe API:

  • Zwraca (pewnie) JSON/XML , który ma być spójny
  • Będzie wykorzystywany przez różne toole, aplikacje, mody
  • Struktura będzie taka sama, żeby zachować kompatybilność w przód

Można zauważyć, że (poza tym że zwracają taki sam kontent w różnych formach) to te dwa API nie mają ze sobą nic wspólnego. Po co więc na siłę tworzyć spójne nazwy?

2
Silv napisał(a):

Ale dlaczego tworzenie spójnych nazw "na siłę"?

  1. Nie trudno wyobrazić sobie sytuację w której zajdzie potrzeba dodania takich zasobów/funkcji w nowym API, które nie mają żadnego odzwierciedlenia w aktualnym i odwrotnie (np. widok pisania postu (GET /Forum/Java/Submit) nie ma żadnego sensu w API "nie dla ludzi"). Wtedy wspólne nazwy staną się problematyczne.
  2. API po angielsku to wręcz prawo wszechświata. Wyobrażasz sobie że chcesz skorzystać z API, a tam zasoby po rosyjsku? /пользователь/14
3

Na github jest już pierwszy endpoint do API, zwracający listę mikroblogów. Pewnie trzeba będzie dodać jeszcze jakąś numeracje wersji - np. api.4programmers.net/v1/... na wszelki wypadek gdyby się coś kiedyś zmieniło :)

0
Adam Boduch napisał(a):

Na github jest już pierwszy endpoint do API, zwracający listę mikroblogów. Pewnie trzeba będzie dodać jeszcze jakąś numeracje wersji - np. api.4programmers.net/v1/... na wszelki wypadek gdyby się coś kiedyś zmieniło :)

Nie ma testów? :D

2

Chodzi mi o to, że gdybyśmy dodali/usunęli jakieś pola z JSON to wtedy stary format zostałby pod URL api.4programmers.net/v1/microblogs a nowy format pod URL api.4programmers.net/v2/microblogs.

Ale nie - nie ma jeszcze testów do API. Mam nadzieje, że może zachęcę społeczność do współtworzenia kodu i ktoś doda pull requesta :)

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