Hostowanie wielu różnych usług na tym samym serwerze i pod tą samą domeną zwykło być proste: skonfiguruj usługi, opcjonalnie ustaw dla nich rekordy MX czy SRV w strefie DNS jeśli działają spod różnych IP, i w zasadzie tyle. Uruchomienie serwerów XMPP, SMTP, POP, IMAP, SSH i HTTP pod tą samą domeną było trywialne, ponieważ domyślnie korzystały z innych portów.

Jednak dzięki web-2.0-izacji Internetu wszystkie nowe usługi zdają się być strasznie uparte, by korzystać z HTTP/HTTPS jako warstwy transportowej. Oznacza to, w skrócie, że nie możesz już uruchomić (na przykład) usług StatusNet i Diaspora na tym samym serwerze – zwyczajnie dlatego, że oba używają portu 80 (lub 443 z SSL/TLS) i mają podobne ścieżki do API. Innymi słowy, nie ma możliwości ustalenia, że dane zapytanie API ma iść do jednej czy drugiej usługi jeśli uruchomione są pod tą samą domeną.

I tak właśnie we wspaniałym wieku XXI udało nam się dokonać ogromnego kroku wstecz – nie możemy już uruchomić różnych usług pod jedną domeną.

Naprawmy to!¶

Przedstawiam services.txt. Podobnie jak robots.txt czy humans.txt jest to plik czytelny dla człowieka, umieszczony w katalogu głównym danej domeny, który informuje wszelkich zainteresowanych (włączając w to, co ważne, inne instancje danej usługi), że gdy szuka się usługi X w tej domenie, należy użyć ścieżki.

Proponowana składnia (aczkolwiek, jak zawsze, zapraszam do dyskusji):

nazwa_usługi/api:wersja:ścieżka

• nazwa_usługi/api: nazwa usługi lub API, których dotyczy dany wpis; w naszym przykładzie byłby to ostatus (StatusNet implementuje protokół OStatus) lub diaspora,
• wersja: numer wersji (np. 1.0), lub gwiazdka (*) oznaczająca, że numer wersji nie ma znaczenia,
• ścieżka: może to być albo lokalna ścieżka (np. /nazwausługi), albo pełny URL jeśli usługa działa z zupełnie innego serwera czy portu.

Wszystkie wpisy zaczynające się od hasza (#) uznawane są za komentarze i ignorowane.

Zatem, gdybym uruchamiał serwer, na którym chciałbym postawić StatusNet (wersję 1.0) oraz Diasporę pod tą samą domeną, przy czym pierwsze działałoby pod /statusnet, a drugie w poddomenie diasp.rys.io po HTTPS i na niestandardowym porcie 9443, mój plik services.txt wyglądałby tak:

# example services.txt file
# for rys.io
ostatus:1.0:/statusnet
diaspora:*:https://diasp.rys.io:9443

Rzecz jasna, wpisy usług są opcjonalne – jeżeli jakiś serwer próbuje skontaktować się z usługą X na naszym serwerze i nie znajduje jej w services.txt (lub nie znajduje tego pliku), po prostu kontaktuje się w sposób domyslny dla danej usługi.