startswith против производительности десериализации JSON?

Question

Я работаю над проектом, в котором я делаю повторный вызов на сервер, который возвращает мне строку JSON в качестве ответа. Если есть какие-либо проблемы, связанные с обслуживанием, то это даст мне либо из них ниже JSON строки в качестве реакции на ошибку -

{"error":"no user_id passed"} 

or 

{"warning": "user_id not found", "user_id": some_user_id} 

or 

{"error": "user_id for wrong partition", "user_id": some_user_id, "partition": some_partition} 

or 

{"error":"no client_id passed"} 

or 

{"error": "missing client id", "client_id":2000} 

Но если это ответ успех, то я получу JSon строку назад, как -

{"@data": {"oo":"1205000384","p":"2047935"} 

Ниже приведен мой код, по которому я звоню, а здесь response переменная будет иметь строку JSON, если что-то пошло не так на стороне обслуживания или если это успех.

RestTemplate restTemplate = new RestTemplate(); 
String response = restTemplate.getForObject(url, String.class); 

// here response has the JSON string 

ClientResponse clientResponse = checkJSONResponse(response); 

return clientResponse; 

В настоящее время я возвращаю ответ, так как он ничего не проверяет. Но теперь я собираюсь проверить ответ и посмотреть, является ли это ошибкой, затем запишите его с определенными ошибками и, если это ответ успеха, верните его.

Первый вариант: - Так я должен десериализации вышеописанный JSON response каждый раз снабжать струной, тетивой и т.п. для каждого вызова, а затем посмотреть, имеет ли успех или ошибочный ответ.

Второй вариант: - Или я должен просто проверить, начинается ли строка ответа с ошибкой или предупреждением, а если она начинается с ошибки или предупреждения, десериализуйте ответ и извлеките конкретные сообщения об ошибках.

Потому что большую часть времени мы получим ответ успеха с данными и только 2% приблизительно, мы получим выше ответ на ошибку, поэтому я думаю, что десериализация каждый раз только для извлечения только случая с ошибкой будет дорогостоящей по сравнению с до startsWith ошибка или предупреждение, а затем десериализация?

Первый Option-

private ClientResponse checkJSONResponse(final String response) throws Exception { 

Gson gson = new Gson(); 
ClientResponse clientResponse = null; 
JsonObject jsonObject = gson.fromJson(response, JsonObject.class); // parse 
if (jsonObject.has("error") || jsonObject.has("warning")) { 

    final String error = jsonObject.get("error") != null ? jsonObject.get("error").getAsString() : jsonObject 
     .get("warning").getAsString(); 

    // log error here 
    ClientResponse clientResponse = new ClientResponse(response, "ERROR_OCCURED", "SUCCESS"); 
} else { 
    ClientResponse clientResponse = new ClientResponse(response, "NONE", "SUCCESS"); 
} 

    return clientResponse; 
} 

Второй Option-

private ClientResponse checkJSONResponse(final String response) throws Exception { 

Gson gson = new Gson(); 
ClientResponse clientResponse = null; 
if(response.startsWith("{\"error\":") || response.startsWith("{\"warning\":")) { 
    JsonObject jsonObject = gson.fromJson(response, JsonObject.class); // parse 
    if (jsonObject.has("error") || jsonObject.has("warning")) { 

     final String error = jsonObject.get("error") != null ? jsonObject.get("error").getAsString() : jsonObject 
      .get("warning").getAsString(); 

     // log error here with specific messages 
     ClientResponse clientResponse = new ClientResponse(response, "ERROR_OCCURED", "SUCCESS"); 
    } 
} else { 
     ClientResponse clientResponse = new ClientResponse(response, "NONE", "SUCCESS"); 
    } 

    return clientResponse; 
} 

, что является лучшим вариантом здесь для моего случая использования? Я в основном смотрю на точку зрения производительности, какой вариант будет более эффективным?

Answer 1

Первый, очевидно, лучше. То, что вы сделали, называется premature optimization. Вы во втором случае сильно подвержены ошибкам, представьте, что произойдет, если элементы будут переупорядочены. Не делайте оптимизаций, пока не убедитесь, что это бутылочная горловина.

UPD: В случае, если вы профилировали код и выяснили, что бесполезный разбор объектов действительно является проблемой. Вы можете назначить коды ошибок, а не передавать строковое значение и использовать метод lastIndexOf() вместо startsWith(). Это помешает вам решить проблему переупорядочения объектов, но будет гарантировать, что слово «ошибка» отсутствует в предупреждающем сообщении.