REST API dla 4programmers.net?

W sumie to przywołuje @msm bo to on zarzucił temat :P

Pojawił się pomysł udostępnienia API dla 4programmers.net. Zakładam ten wątek, aby można było przedyskutować pewne tematy jak:

1. Po co?
2. Dla kogo?
3. Jaki zakres funkcjonalności?
4. Tylko do odczytu czy możliwość publikowania (np. wpisów mikrobloga czy w przyszłości ofert pracy?)

Zakładam, ze @msm miał tutaj na myśli konkretnie API do forum, aby warto by było założyć, że w przyszłości takie API byłoby rozbudowane o np. dział z ofertami pracy czy mikroblogami.

Zapraszam do dyskusji. Jak coś się tutaj wykluje to zbiorę to do kupy i pozakładam zadania na github.

To skoro zostałem przywołany...

Pomysł się zrodził już jakiś czas temu, bo co najmniej kilka pytań o API do 4p widziałem (nawet w kontekscia aplikacji mobilnej).

A teraz coś się ruszyło, bo pewien użytkownik (@kq konkretnie) chciał napisać 4programmers.netowego bota do IRC (bot z tego co wiem już napisany i działa btw).

W każdym razie potrzebował funkcji pobierania najnowszych tematów na forum (żeby bot robił powiadomienia), i pierwszy pomysł to było parsowanie strony głównej forum w poszukiwaniu nowych tematów.
Jako że to jest chory pomysł (parsowanie HTMLa tylko po to żeby kilka pól wyciągnąć), stanęło na prostym API do tego (ostatnie 10 tematów w JSONie).

No i to testowe API stoi już i ma się dobrze (nie jest dostępne publicznie, bo to efektywnie hack na kolanie i ten wątek jest po to żeby ustalić co dalej, ale jeśli ktoś jest zainteresowany "na już" to można napisać PW).

To skoro background za nami, to jeszcze coś konstruktywnego odpowiem na pytania:

Po co?

Programiści to zazwyczaj kreatywne istoty, jeśli dać im taką możliwość to mogą zrobić coś przydatnego.
Use casów dla api jest masa, chociażby wspomniany bot do irca (ja kiedyś napisałem jeszcze inne api, i jeszcze bardziej na kolanie, do bota XMPPowego, ale to było dawno (jeszcze na poprzednim serwerze) a tamten bot w końcu nie ruszył nigdy).

Jaki zakres funkcjonalności?

Zakładam, ze @msm miał tutaj na myśli konkretnie API do forum, aby warto by było założyć, że w przyszłości takie API byłoby rozbudowane o np. dział z ofertami pracy czy mikroblogami.

Na pewno wątki i posty na forum (jak Adam napisał), bo to na razie najbardziej aktywna częśc 4p. W przyszłości inne działy też są opcją, ale trzeba się zastanowić które - takie np. API dla ofertów pracy by było przydatne gdyby ktoś się z nim integrował/go używał. Nie mam pojęcia jak wygląda sprawa API dla ofert pracy, kto wie, może jest jakiś standard :P.

Tylko do odczytu czy możliwość publikowania (np. wpisów mikrobloga czy w przyszłości ofert pracy?)

Na pewno możliwośc publikowania by dramatycznie zwiększyła przydatność takiego API. Tylko trzeba by się zastanowić nad bezpieczeństwem tego, bo nie chcemy żeby jakiś abuser za pomocą trzylinijkowego skryptu w javascripcie puszczonego w nocy dodał 500 tysięcy postów do bazy ;).

@msm pewnie, że działa ;D

msm napisał(a):

Jako że to jest chory pomysł (parsowanie HTMLa tylko po to żeby kilka pól wyciągnąć), stanęło na prostym API do tego (ostatnie 10 tematów w JSONie).

Nie to żebym się czepiał, ale do tego akurat to by chyba wystarczył rss, który jak widzę tu jest. Czyli xml a nie prasowanie strony.

Co do klienta mobilnego, to może być i nawet komunikować się przez te api restowe, tylko po co wymyślać koło na nowo zamiast dodać obsłigę taptalk?

Nie to żebym się czepiał, ale do tego akurat to by chyba wystarczył rss, który jak widzę tu jest. Czyli xml a nie prasowanie strony.

RSS sie generuje (nie wiem czemu w sumie) 500 ms, więc trzeba by go najpierw zoptymalizować. Ale racja, wystarczyłby (chociaż by był mniej wygodny), tylko mówilem o pierwszym pomyśle :P.

Odnośnie klienta mobilnego to nie twierdze żę to najlepszy sposób, tak tylko wspomniałem bo sobie przypomniałem o nim. Nie wiem w sumie co to taptalk, ale brzmi mądrze.

Taptalk to klient mobilny do forum. Mam wrażenie że już tu upominano się nie raz o obsługę taptalka

Miałem napisać o tym trochę później, jak już zrobię w miarę używalną wersję, ale skoro poruszyliście tu ten temat... Piszę w ramach projektu do portfolio/nauki mobilną apkę 4programmers na Androida. Obecnie więcej funkcji nie ma niż jest, ale to bardzo wczesna wersja. Korzystam z parsowania HTML i działa dość dobrze. Myślę, że REST API mogłoby się bardzo przydać. Jeśli ktoś jest zainteresowany mogę napisać mikrobloga/temat na forum gdzie dokładniej opisze apkę, dodam screeny itp. Jest ktoś taki?

Tak btw.
Nie jestem tu nowy, śledzę to forum od dłuższego czasu, a nowe konto założyłem, bo trochę wstyd mi za stare posty i tematy napisane gdy dopiero zaczynałem naukę :D.

@Hobbajt: pewnie, pochwal się na mikroblogu. Tylko weź pod uwagę, że po wydaniu nowej wersji 4programmers.net, zmieni się struktura kodu HTML tak więc aplikacja przestanie działać poprawnie.

Z tego co przeglądałem nową wersję, to zmienić będę musiał tylko kod odpowiadający za parsowanie. Struktura strony jest podobna do obecnej, więc nie powinno być źle :). Zauważyłem też kilka zmian, które trochę ułatwią parsowanie.

Hobbajt napisał(a)

Jeśli ktoś jest zainteresowany mogę napisać mikrobloga/temat na forum gdzie dokładniej opisze apkę, dodam screeny itp. Jest ktoś taki?

Zamiast pytać się czy ktoś jest zainteresowany, weź po prostu załóż wątek w tym dziale lub w Oceny i recenzje :]

jakby było rest api z wieloma funkcjonalnościami to byłoby mega. Napisałabym sobie bota. DAWAJCIE !!!

W takim razie można by było zachować obecną strukturę URL-i dla WWW i generować odpowiedź w JSON jeżeli odwołanie pochodziłoby do subdomeny api.4programmers.net. Czyli np.:

4programmers.net/Forum => Wersja HTML
api.4programmers.net/Forum => JSON

Podstawową trudność jaką widzę to to, że API powinno być wersjonowane. Czyli mielibyśmy adres: api.1-0.4programmers.net/Forum albo api.4programmers.net/1.0/Forum tak, aby ewentualnie zmiany nie powodowały, że nagle wywalą się aplikacje korzystające z API. No i oczywiście testy każdego kontrolera API.

Czy wypluwane przez API JSON-owe wyniki będą zbliżone (a może też w 100% zgodne) ze specyfikacją określoną tutaj?

http://jsonapi.org/

Czy też może według własnej specyfikacji?

Prawdę mówiąc to json-api pod linkiem wyżej wygląda dość ciekawie, nawet są i biblioteki do PHP na githubie, więc co o tym sądzicie?

Idąc dalej, w jakiej postaci będą zabezpieczenia? API key dla programisty (md5, sha1), Basic Authentication, Digest Authentication czy coś innego?

drorat1 napisał(a):

Czy wypluwane przez API JSON-owe wyniki będą zbliżone (a może też w 100% zgodne) ze specyfikacją określoną tutaj?

http://jsonapi.org/

Czy też może według własnej specyfikacji?

Właściwie to nie wiem... dla mnie wygląda ok. Jakieś opinie przeciw?

Niczego tu w zasadzie nie sugeruję. Ale dość dobrze opracowane bo np: to:

GET /articles?page[number]=3&page[size]=1 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "meta": {
    "total-pages": 13
  },
  "data": [
    {
      "type": "articles",
      "id": "3",
      "attributes": {
        "title": "JSON API paints my bikeshed!",
        "body": "The shortest article. Ever.",
        "created": "2015-05-22T14:56:29.000Z",
        "updated": "2015-05-22T14:56:28.000Z"
      }
    }
  ],
  "links": {
    "self": "http://example.com/articles?page[number]=3&page[size]=1",
    "first": "http://example.com/articles?page[number]=1&page[size]=1",
    "prev": "http://example.com/articles?page[number]=2&page[size]=1",
    "next": "http://example.com/articles?page[number]=4&page[size]=1",
    "last": "http://example.com/articles?page[number]=13&page[size]=1"
  }
}

I można sobie stronicować wyniki w JSON z użyciem linków albo pobierać i wszystkie, robiłem coś wg. tego i naprawdę fajne rozwiązanie i fajnie to działa.

No i to:

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/vnd.api+json

{
  "errors": [
    {
      "status": "422",
      "source": { "pointer": "/data/attributes/first-name" },
      "title":  "Invalid Attribute",
      "detail": "First name must contain at least three characters."
    }
  ]
}

Czyli w przypadku wystąpienia błędu są jasne informacje czego to dotyczy.

Odświeżam wątek. Czyli podsumowując założenia:

• API pod subdomeną: api.4programmers.net
• Format danych: JSON API (http://jsonapi.org/)
• Wersjonowanie API? Tzn. URL wyglądałoby tak: api.4programmers.net/1.0/Forum, api.4programmers.net/1.1/Forum itp
• Biblioteka: http://fractal.thephpleague.com/

Nie miałem jeszcze styczności, ale "mówi się" [citation needed], że http://graphql.org/ to "następca" REST i nie ma potrzeby wersjonowania przy rozwoju. Może jest tu jakiś spec, który potwierdzi bądź zaprzeczy i ogólnie wypowie się w temacie czy warto, czy jednak zostać przy wersji klasycznej?

Marooned napisał(a):

Nie miałem jeszcze styczności, ale "mówi się" [citation needed], że http://graphql.org/ to "następca" REST i nie ma potrzeby wersjonowania przy rozwoju. Może jest tu jakiś spec, który potwierdzi bądź zaprzeczy i ogólnie wypowie się w temacie czy warto, czy jednak zostać przy wersji klasycznej?

Podbijam temat w związku z pytaniem zadanym przez @Marooned. Robimy REST API czy GraphQL API? Jednak GraphQL to wciąż nowość, REST istnieje już od lat.

Czesc czy prace nad publicznym api stoja w miejscu lub jest juz cos?

Niestety stoją w miejscu, ale jesteśmy otwarci na pomoc w tej kwestii :))

Zaczęły się dawno temu, ale z powodów technicznych stanęły i nie zanosi się żeby poszły do przodu :P. Ale jak ktoś napisze...