2013-07-15 2 views
0

Я работаю над приложением, которое в основном работает с API, который будет установлен во внутренней системе. API также доступен через общедоступный Интернет. Клиент хочет разрешить пользователям вводить как внутренний, так и внешний (общедоступный интернет) URL-адрес, который приложение будет подключать в зависимости от наличия внутренних и внешних URL-адресов.Переключение между различными хостами API

Приложение в основном выполнено за исключением того, что оно в настоящее время подключается к внутреннему URL только для всех его вызовов API. Я использую AFNetworking с блочными вызовами завершения/сбоя для каждого вызова API.

Основываясь на логике, которую мы разработали, приложение всегда будет проверять наличие API, запрашивая текущее время сервера. Это делается путем вызова http://internal_url/api/time. Если этот API не сможет ответить на соответствующий ответ, мы перейдем на внешний URL http://external_url/api/time и назовем тот же API по этому URL. Если оба отказались, приложение сообщит об этом пользователю и не выполнит никаких других запросов к API.

Не раскрывая слишком много, вот некоторые кода о том, как я на API вызовы в настоящее время установки:

- (void)someAPIMethodCall:(NSDictionary *)parameters completionBlock:block failure:block { 
// query /api/time and return the URL (internal/external) that is currently up 

AFHTTPClient *client = [AFHTTPClient clientWithBaseURL:<url returned from above query>]; 
[client operationWithSuccess:block failure:block]; 
} 

Так что мой вопрос будет: что это лучший способ, чтобы получить метод запроса /api/time выше для работы? Очевидно, что этот метод должен заполнить и вернуть либо внутренний/внешний URL-адрес, чтобы использовать последующий фактический запрос API. AFAIK, вызовы AFNetworking основаны на блоках, поэтому они возвращаются до того, как выйдет /api/time. Я также думал о отдельном классе, который синхронно использует NSURLConnection, который будет блокировать основной поток, пока он ждет возвращения /api/time.

+0

Как только вы определяете 'internal_url' и' external_url', это когда-либо меняется в течение всего срока службы приложения? –

+0

@AaronBrager Поскольку предпочтительнее, чтобы мы подключались к API, который размещен внутри компании, наша логика - проверить системное время и вернуться к использованию 'internal_url' в точке часа. P/S: Я не придумал эту логику, клиент сделал. – XCool

ответ

1

Я хотел бы сказать вам, что вы просто используете один и тот же URL-адрес внутри и снаружи (через DNS), но это не то, что вы хотите.

Я думаю, вы спрашиваете, как условно назвать другой URL.

Вы хотите, чтобы некоторый APIMethodCall был асинхронным ... поэтому вы не хотите блокировать вызов для проверки правильности вызова api.

Помимо кеширования результатов, поэтому вам не нужно делать это каждый раз, вы просто хотите вызвать другой собственный метод на основе блока, который имеет блок завершения, который передает IN параметра URL-адреса, чтобы вызвать ваш реальный запрос.

- (void)someAPIMethodCall:(NSDictionary *)parameters completionBlock:(void (^)(void))succesBlock failure((^)(void)):failureBlock { 
    [self callBlockWithMyApiUrl:^(NSString *apiUrl){ 
     AFHTTPClient *client = [AFHTTPClient clientWithBaseURL:apiUrl]; 
     [client operationWithSuccess:successBlock failure:failureBlock]; 
    } onFailure:^{ 
     failureBlock 
    } 
} 

- (NSString *)callBlockWithMyApiUrl:(NSString * (^)(void))success (void (^)(void))failure 
{ 
    // Your code to test for the working URI 
    // If you're doing it this way, I'd suggest caching the result. 
    // Subscribe to networking interface changes to dump the cache. 
} 
+0

Спасибо! Я следовал этому методу, и в настоящее время я успешно его реализовываю. – XCool

Смежные вопросы