Nuno zaczął prace nad nowym API resztowym

Miło mi poinformować, że użytkownik nuno69 zaczął prace nad nowym API resztowym dla Eltena. Z tego miejsca bardzo mu dziękuję.
API resztowe (RESTful API) to interfejs instalowany na serwerze, który jest wykorzystywany przez klientów do komunikacji. Rozwijane rozwiązanie posłuży zarówno klientom mobilnym, stronie Internetowej, jak przyszłym (po 2.4) wersjom klienta desktopowego. Oznacza to, że prace nad klientami mobilnymi są wstrzymane do momentu osiągnięcia sensownej funkcjonalności API.
Pozwoli to w przyszłości na dużo szybsze rozwijanie kolejnych platform dla Eltena.

API rozwijane jest w języku C#, w technologii ASP.NET.
Wszystkie osoby pragnące pomóc proszę o kontakt z nunem. Z góry bardzo dziękuję.

Z uszanowaniem,
Dawid Pieper

Dokładnie to ASP .NET CorE, wersja 3.1, jak na razie. Postaram się dokonać jak najlepszych starań, żeby wszystko działało, jak należy.

Gratki, powodzenia. :)

Oo. POzostaje mi życzyć powodzenia a także zapału do pracy!

Na pewno się przyda :)

Gratuluję i życzę owocnej współpracy.

:) powodzenia

Powodzenia i wytrwałości :)

Utworzyłem repozytorium na GitHubie, na razie prywatne, na potrzeby projektu. Jeśli ktoś byłby chętny do współpracy, prosiłbym o informację w tym wątku, to go dodam. ;)
Z góry dziękuję.

Z ciekawości, czy API to tak właściwie backend, który uzyskuje bezpośredni dostęp do bazy i ją pyta o co trzeba, czy raczej nakładka na obecne rozlatujące się php? Jakie będą warunki użycia? Jak przebiega logowanie, zakładając zewnętrzne klienty? Podajemy hasło w aplikacji metodą najprostrzą i najprzyjaźniejszą dla użytkownika ale liczymy, że deweloper nie wykradnie, czy przenoszeni jesteśmy na bezpieczną stronę Eltena i autoryzujemy się oAuth, dając odpowiednie uprawnienia? Jak będzie wyglądać polityka CORS? Co z dostępem do zasobów z gruntu publicznych (forum, blogi), czego będzie to wymagać? Logowania? Klucza aplikacji? Niczego? Jak rozwiązana będzie kwestia uploadu/downloadu audio? Jakie rozszerzenia? Jaka weryfikacja jakośći i parametrów kodowania plików wysyłanych, żeby użytkownik nie naruszał warunków wersji free? Czy rozważona jest kwestia, jakie kodeki są przez jakie platformy obsługiwane, w tym w przeglądarkach, i na którym etapie procesu (jeśli w ogóle) dokonywać transcodingu? Po czym i jak działają pisane rozmowy głosowe, i jak wygląda przyszła kompatybilność tego z tym API? Jak obsługiwane są powiadomienia, websocket, long polling czy coś jeszcze innego? Co z blogami? Co z procesem rejestracji, w API czy jednak nie? Jakie zabezpieczenia przed spamem? W ogóle jak wygląda kwestia z zabezpieczeniami przed nadużyciem? Limity API calls? Coś innego?

Odpowiadam pod pytaniami.

Z ciekawości, czy API to tak właściwie backend, który uzyskuje bezpośredni dostęp do bazy i ją pyta o co trzeba, czy raczej nakładka na obecne rozlatujące się php?
Zupełnie nowe API komunikujące się z bazą danych.

Jakie będą warunki użycia?
Nie przewiduję ograniczeń co do zasad użycia, choć decyzji ostatecznej nie ma. Choć na pewno będą ograniczenia quota.

Jak przebiega logowanie, zakładając zewnętrzne klienty? Podajemy hasło w aplikacji metodą najprostrzą i najprzyjaźniejszą dla użytkownika ale liczymy, że deweloper nie wykradnie, czy przenoszeni jesteśmy na bezpieczną stronę Eltena i autoryzujemy się oAuth, dając odpowiednie uprawnienia?
Na potrzeby aplikacji desktopowej i mobilnej na pewno logowanie prosto z aplikacji. Nie wiem, czy dla innych programów będzie wymagane OAuth, nie myślałem jeszcze o tym.

Jak będzie wyglądać polityka CORS?
Publicznie dostępne, czyli any origin.

Co z dostępem do zasobów z gruntu publicznych (forum, blogi), czego będzie to wymagać? Logowania? Klucza aplikacji? Niczego?
Prawdopodobnie klucza aplikacji, by nie przekroczyć nam quoty.

Jak rozwiązana będzie kwestia uploadu/downloadu audio? Jakie rozszerzenia? Jaka weryfikacja jakośći i parametrów kodowania plików wysyłanych, żeby użytkownik nie naruszał warunków wersji free?
Chyba tak, jak do tej pory, czyli accept anything that can be converted by ffmpeg to Opus, jak dostaniesz Opusa o odpowiednim bitrate, wrzucaj, jak nie, konwertuj.

Po czym i jak działają pisane rozmowy głosowe, i jak wygląda przyszła kompatybilność tego z tym API?
Rozmowy głosowe są pisane z myślą o słabych łączach, nie są pisane po HTTP i nie dotyczą tego API raczej. One też używają JSON w warstwie TCP, ale trudno mówić tu o jakiejś wzajemnej zgodności. One w ogóle nie używają HTTP, tylko czystego TCP i UDP.

Jak obsługiwane są powiadomienia, websocket, long polling czy coś jeszcze innego?
Obecnie powiadomienia są kolejkowane w bazie danych i wypychane przy pierwszym zapytaniu. To najlepsza technika dla aplikacji desktopowej, ale nie mobilki czy websocket. Jak tam będzie? Zobaczymy, to moje ostatnie zmartwienie na razie, bo system jest bardzo łatwy do modyfikacji.

Co z blogami?
Blogi działają na Wordpressie. Pewnie będą też oskryptowane w API ze względu zgodności i ułatwienia pewnych zapytań, ale API WP pozostaje otwarte i nasze API będzie na nie tylko nakładką, z resztą już teraz tak jest.

Co z procesem rejestracji, w API czy jednak nie?
Zakładam, że rejestracja będzie możliwa tylko dla poszczególnych, wybranych aplikacji, prawdopodobnie tylko i wyłącznie dla strony oraz klienta PC.

Jakie zabezpieczenia przed spamem? W ogóle jak wygląda kwestia z zabezpieczeniami przed nadużyciem? Limity API calls? Coś innego?
Pisałem wyżej, myślę o limicie quota. Nie wiem tylko, czy per app, per ip, czy jedno i drugie.

co do limitów, proponuję metodę Twittera, czyli osobny limit per app, i osobny limit dla kombinacji {app,user}, żeby aplikacja nie zginęła przez swoją popularność.

Co do rozmów głosowych, rozumiem, że na kompatybilność tego ze stroną, względnie z mobilką, nie ma co liczyć?

Na pewno obsługa rozmów głosowych będzie w aplikacji mobilnej, powiem więcej, moim zdaniem dopiero tam nabierze ona prawdziwego sensu. Po prostu nie będzie szła po tym samym API.
Co do strony, nie wiem. Dałoby się, ale ja nie czuję się ekspertem w sprawach Javascriptowych, API WebRTC i tak dalej. I nie wiem, czy będę miał czas się w tej sprawie doszkalać, zwłaszcza, że wątpię, by taka funkcja na stronie była popularna.
99 procent użytkowników Windowsa na razie instaluje klienta i nie wydaje się, by proporcje te się zmieniły. Jeśli się oczywiście zmienią, zmienią się też priorytety.

Warto tu zauważyć, że obecnie informacja o samej próbie nawiązania połączenia to zwykłe powiadomienie i dopiero po jego odebraniu aplikacja przeskakuje w API VoIP. Co jest do adaptacji na iOS/Android bardzo proste.

No, na ios/android będzie kwestia, czy się bawić, udawać, że jesteśmy appką do nagrywania filmów ala team talk i dostawać pewną inną obsługę audio, czy jednak iść w typowe voip i tracić np. na jakości

Tym będziemy się martwić na samym końcu. ;)
Najpierw niech dostaniemy cokolwiek, co chociaż działa.

I jak tam praca? :)