Комментарии 9
Некоторые классические ошибки. С ходу и сразу:
- Кодировка ответа. Если точно знаете в какой кодировке (UTF-8, например), то не забудьте указать InputStreamReader(.., StandardCharsets.UTF_8). Иначе будут сюрпризы на разных OS. А если не знает, то нужно бинарные данные считывать и брать String исходя из заголовка HTTP ответа.
- А где анализ статуса? Хотя бы, что ни будь типа (упрощено для наглядности): connection.getResponseCode() == 200? connection.getInputStream(): connection.getErrorStream();
- Не стоит забывать про connection.setConnectTimeout(..) и connection..setReadTimeout(..) (в реальных проектах).
Зачем все эти обертки, если можно connection.getOutputStream().write(reqBody.getBytes(StandardCharsets.UTF_8));
И всегда нужно указывать кодировку. Или осознанно не указывать, рассчитывая на кодировку по умолчанию OS или указанную при запуске Java. Но это должно быть именно осознанное решение.
И, хотя, в данном случае, кодировка не принципиальна (текст Ascii), но надеяться на кодировку по умолчанию для Java — не стоит.
\r\n – символ CRLF – вставляет переход на новую строку
Ну нельзя же так. Мир не заканчивается на Windows. Да и сам подход чтения через BufferedReader с записью в StringBuilder ну просто вырвиглаз..
Или это пример под конкретный вызов из под конкретной OS, к конкретному сервису? Типа "оно же работает!"
(предвижу этот аргумент, как ответ на мои замечания).
Где например сравнение HttpUrlConnection vs HttpsUrlConnection?
Про кодировку потока, таймауты и обработку ошибок выше уже написали.
А здесь написан сомнительный код, которым нельзя будет воспользоваться, если условия работы с каким-нибудь интернет сервисом хоть немного изменятся.
Будь у меня возможность голосовать, поставил бы стрелочку вниз, уж простите.
reader.lines().forEach(l -> respBody.append(l + “\r\n”);
Во-первых, лучше использовать System.lineSeparator()
вместо \r\n
Во-вторых, можно написать
return reader.lines().collect(Collectors.joining(System.lineSeparator()))
и использовать try-with-resources
Заинтересовала возможность получения информации о пользователях, используя Slack API.
А зачем писать свой велосипед, если в последних версиях Java появился HTTP-клиент?
Особенности HttpUrlConnection из java.net