Config JSON

URL

Do czego służy JSON na URL?

Masz obiekt JSON, który opisuje części endpointu HTTP — protocol, host, ścieżkę, parametry query, hash — i potrzebujesz go jako jednego ciągu URL, który fetch(), curl albo Twój klient HTTP zdoła przełknąć. Wklej JSON po lewej, dostaniesz złożony, zakodowany procentowo URL po prawej. Ten sam kierunek, który prędzej czy później musi wyprodukować każdy fixture testowy backendu, każdy przykład z OpenAPI i każdy plik konfiguracyjny.

Korzysta z natywnego konstruktora URL z przeglądarki i URLSearchParams do złożenia adresu, więc kodowanie jest dokładnie takie, jakie definiuje standard URL WHATWG i dokładnie takie, jakie wysłałaby prawdziwa przeglądarka. Spacje w query stają się +, nawiasy kwadratowe %5B/%5D, znaki diakrytyczne i emoji idą jako UTF-8 zakodowane procentowo. Powtarzające się klucze query obsługujesz przez tablicę — "tag": ["red", "blue"] daje tag=red&tag=blue.

Ta strona istnieje, bo większość projektów i tak gdzieś trzyma URL-e jako JSON — pliki environment, kolekcje Postmana, fixtury Cypress, specyfikacje OpenAPI, values Helma. Kiedy potrzebujesz takiego JSON-a jako prawdziwego ciągu URL do skryptu albo jednorazowego curl-a, ręczne sklejanie to miejsce, w którym kryją się bugi. Konwersja podąża za RFC 3986 w kwestii składni URL i przyjmuje na wejściu standardowy JSON wedle RFC 8259. Wszystko leci lokalnie — ani JSON, ani URL nie opuszczają Twojej przeglądarki. Kierunek odwrotny mieszka pod adresem URL na JSON.

Jak zamienić JSON w URL

Trzy kroki. Każdy odpowiada przyciskowi na tej stronie.

Wklej config JSON albo wczytaj przykład

Po lewej upuść obiekt JSON opisujący części URL-a. Jedyne wymagane pola to protocol i host; reszta jest opcjonalna. Kliknij Przykład, żeby wczytać realistyczny endpoint e-commerce z kilkoma parametrami query i hashem:

{
  "protocol": "https",
  "host": "api.shop.example.com",
  "pathname": "/v1/orders",
  "searchParams": {
    "customer": "Ava Chen",
    "status": "active",
    "total[gte]": "49.99",
    "page": "2"
  },
  "hash": "summary"
}

Pola opcjonalne: port, username, password, pathname, searchParams, hash. Wewnątrz searchParams string to pojedyncza wartość, tablica to powtarzane klucze. Składnię JSON parsuje JSON.parse — bez komentarzy, bez przecinków na końcu.

Odczytaj złożony URL

Prawy panel aktualizuje się na bieżąco. Zobaczysz pełny URL — https://api.shop.example.com/v1/orders?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2#summary — z każdą częścią zakodowaną procentowo tak, jak definiuje to standard URL. Wrzuć go wprost do wywołania fetch(), do polecenia curl, do testu Postmana albo do pliku konfiguracyjnego oczekującego pojedynczego ciągu URL.

Skopiuj albo pobierz

Klikając Kopiuj, wysyłasz URL do schowka, klikając Pobierz — zapisujesz go jako plik tekstowy. Użyj Wyczyść w panelu wejścia, żeby zacząć od nowa ze świeżym configiem.

Kiedy faktycznie tego użyjesz

Zamiana przykładów z OpenAPI w działające polecenia curl

Specyfikacje OpenAPI opisują serwery jako {url, variables}, a operacje jako ścieżki z parameters. Sklejanie z tych kawałków właściwego URL-a do jednorazowego curl-a ręcznie jest upierdliwe — podstawianie zmiennych ścieżki, kodowanie parametrów query, dopilnowanie ukośnika na końcu. Wrzuć tu sklejony JSON, skopiuj URL, wklej w curl. Sklejona forma odpowiada temu, co opisuje server-object w OpenAPI.

Budowanie URL-i z rozbitych zmiennych środowiskowych

Aplikacja 12-factor trzyma części URL-a jako osobne env vary: API_HOST, API_PORT, API_BASE_PATH, API_TOKEN_PARAM. Żeby w trakcie incident response wyprodukować pełny URL pod sanity-checkowy curl, składasz je. Wklej formę JSON do tej strony, weź URL, odpal. Szybsze niż skryptowanie w bashu i bez ryzyka, że zapomnisz zakodować tokenu z +.

Fixtury Cypressa i Playwrighta przechowujące URL-e jako obiekty

Fixtury testowe często trzymają URL-e żądań w ustrukturyzowanej formie, żeby móc asercjować na poszczególnych częściach (path param orderId, query param page). Kiedy fixtura musi też wykonać prawdziwe wywołanie HTTP (np. żeby zasiać dane przez cy.request albo page.goto), forma ustrukturyzowana musi się stać stringiem. JSON na URL zamienia zapisany przez Marco Riverę obiekt fixtury w URL, w który harness testowy może uderzyć.

URL-e webhooków składane z configów per tenant

Systemy multi-tenant trzymają configi webhooków per klient: {host: "hooks.tenant-a.example.com", pathname: "/orders/ORD-1001/notify", searchParams: {token: "..."}}. Dispatcher czyta JSON i potrzebuje ciągu URL, na który wywoła POST. Ta sama konwersja, którą robi ta strona, tylko w runtime. Wykorzystaj stronę, żeby sprawdzić, czy URL, który wyprodukuje Twój kod, zgadza się z tym, co zarejestrował klient.

Najczęstsze pytania

Jaka jest różnica między tym a stroną URL Builder?

Ten sam silnik, inne ujęcie. URL Builder jest dla sytuacji, w której siadasz, żeby od zera zbudować URL — komponujesz request. JSON na URL jest dla sytuacji, w której JSON już gdzieś istnieje (config, spec OpenAPI, fixtura, rozbicie env varów) i musisz przerobić go na ciąg URL, którego oczekuje kawałek kodu. Wybierz to ujęcie, które pasuje do tego, co robisz — wynik jest identyczny.

Mój JSON trzyma URL inaczej — czy mogę użyć dowolnej formy?

Trzeba użyć nazw części URL ze standardu WHATWG: protocol, host, port, username, password, pathname, searchParams (obiekt), hash. Jeśli Twój JSON używa innych kluczy (scheme, baseUrl, query, fragment), najpierw je przemianuj. Forma odzwierciedla to, co eksponuje new URL(...) i co definiuje spec URL, więc wpasowujesz się w ten sam model, którego wewnętrznie używają fetch i Node.

Jak wysłać ten sam parametr query dwa razy (np. ?tag=red&tag=blue)?

Użyj tablicy jako wartości: "tag": ["red", "blue"]. Konwerter wypluwa tag=red&tag=blue w podanej kolejności. Pasuje to do tego, jak URLSearchParams obsługuje powtarzane klucze, i jest tym, czego oczekuje większość serwerów (Express, Rails, ASP.NET) dla parametrów query w stylu tablicowym.

Dlaczego moja spacja staje się + zamiast %20?

Spacje w komponencie query są kodowane jako + zgodnie z regułami application/x-www-form-urlencoded — tak właśnie wypluwa to URLSearchParams. Spacje w ścieżce są kodowane jako %20. Obie formy są poprawne wedle RFC 3986 i każdy serwer dekoduje obie. Jeśli Twój serwer w query akceptuje wyłącznie %20, błąd jest po stronie serwera.

Czy mogę zaszyć dane uwierzytelniające (login/hasło) w URL-u?

Tak — ustaw w JSON-ie "username" i "password". Pojawią się przed hostem jako user:pass@host. RFC 3986 §3.2.1 ostrzega przed tym w produkcyjnych URL-ach, bo lądują w historii przeglądarki, logach serwera i cache'u proxy — ok do szybkiego lokalnego testu, nie ok we współdzielonych configach.

Czy URL kiedykolwiek opuszcza moją przeglądarkę?

Nie. Parsowanie JSON-a to JSON.parse w Twojej karcie; składanie URL-a to new URL(...) w Twojej karcie; żadne z nich nie woła serwera. Brak uploadu, brak logowania. Możesz raz otworzyć stronę z internetem, potem się rozłączyć i dalej korzystać z niej z cache'u.

Inne narzędzia URL i JSON

JSON na URL to połowa rundy w obie strony. Reszta zestawu: