NSURL URLWithString: relativeToURL: jest obcięcie względnego adresu URL

Question

Próbuję zaimplementować aplikację na iOS, która korzysta z pakietu RestKit. We wszystkich przykładach widziałem dotąd następujący kod służy do tworzenia adresów URL:

NSURL *baseURL = [NSURL URLWithString:@"https://api.service.com/v1"]; 
NSURL *relativeURL = [NSURL URLWithString:@"/files/search" relativeToURL:baseURL]; 

Ale wtedy [relativeURL absoluteString] powróci https://api.service.com/files/search.

Więc próbowałem kilka przykładów:

NSURL *baseURL1 = [NSURL URLWithString:@"https://api.service.com/v1/"]; 
NSURL *baseURL2 = [NSURL URLWithString:@"https://api.service.com/v1"]; 
NSURL *baseURL3 = [NSURL URLWithString:@"/v1" relativeToURL:[NSURL URLWithString:@"https://api.service.com"]]; 

NSURL *relativeURL1 = [NSURL URLWithString:@"/files/search" relativeToURL:baseURL1]; 
NSURL *relativeURL2 = [NSURL URLWithString:@"/files/search" relativeToURL:baseURL2]; 
NSURL *relativeURL3 = [NSURL URLWithString:@"/files/search" relativeToURL:baseURL3]; 
NSURL *relativeURL4 = [NSURL URLWithString:@"files/search" relativeToURL:baseURL1]; 
NSURL *relativeURL5 = [NSURL URLWithString:@"files/search" relativeToURL:baseURL2]; 
NSURL *relativeURL6 = [NSURL URLWithString:@"files/search" relativeToURL:baseURL3]; 

NSLog(@"1: %@", [relativeURL1 absoluteString]); 
NSLog(@"2: %@", [relativeURL2 absoluteString]); 
NSLog(@"3: %@", [relativeURL3 absoluteString]); 
NSLog(@"4: %@", [relativeURL4 absoluteString]); 
NSLog(@"5: %@", [relativeURL5 absoluteString]); 
NSLog(@"6: %@", [relativeURL6 absoluteString]); 

i to jest wyjście:

1: https://api.service.com/files/search 
2: https://api.service.com/files/search 
3: https://api.service.com/files/search 
4: https://api.service.com/v1/files/search 
5: https://api.service.com/files/search 
6: https://api.service.com/files/search 

Więc jedynym przykładem powrocie czego chcę to # 4. Czy ktoś może wyjaśnić, dlaczego?

Answer 1

czytam [RFC1808] który określa algorytm normatywnego rozwiązywania względnych adresów URL

2 problemy:

1. względny adres URL nie może zaczynać się od/lub jest uznawany za absolutny:

   Step 4: If the embedded URL path is preceded by a slash "/", the 
       path is not relative and we skip to Step 7." 
   

2. , gdy końcowy URL kończy się na niezawierającym slashu. wszystko z ostatniego ukośnik ON jest pomijany

   Step 6: The last segment of the base URL's path (anything 
       following the rightmost slash "/", or the entire path if no 
       slash is present) is removed and the embedded URL's path is 
       appended in its place. The following operations are 
       then applied, in order, to the new path:" 
   

więc to wszystko wyjaśnia. baseURL musi kończyć się a/i względny adres URL nie powinien zaczynać się/

Answer 2

masz dwa problemy tutaj:

Po pierwsze, ciąg /files/search jest absolutny ścieżka, ponieważ rozpoczyna się ukośnikiem . Rozpatrzenie go pod dowolnym istniejącym adresem URL zignoruje istniejącą ścieżkę.

Po drugie, https://api.service.com/v1 nie ma końcowego ukośnika wskazującego, że jest to katalog. Dowolne łańcuchy rozwiązane przeciwko niemu zawsze będą ignorować część v1.

Podsumowując, potrzebna jest kombinacja względnej ścieżki - files/search - oraz podstawowy adres URL katalogu - https://api.service.com/v1/.

Answer 3

Inny przykład:

//it's right 
NSURL *url = [NSURL URLWithString:@"getValidNumber" relativeToURL:[NSURL URLWithString:@"http://dns.test.com:22009/service/"]]; 

//error 
NSURL *url = [NSURL URLWithString:@"getValidNumber" relativeToURL:[NSURL URLWithString:@"dns.test.com:22009/service/"]]; 

//error 
NSURL *url = [NSURL URLWithString:@"/getValidNumber" relativeToURL:[NSURL URLWithString:@"http://dns.test.com:22009/service"]]; 

` do 'http: //' jest niezbędne do korzystania z tej metody.