Особенности HttpUrlConnection из java.net

Некоторые классические ошибки. С ходу и сразу:

1. Кодировка ответа. Если точно знаете в какой кодировке (UTF-8, например), то не забудьте указать InputStreamReader(.., StandardCharsets.UTF_8). Иначе будут сюрпризы на разных OS. А если не знает, то нужно бинарные данные считывать и брать String исходя из заголовка HTTP ответа.
2. А где анализ статуса? Хотя бы, что ни будь типа (упрощено для наглядности): connection.getResponseCode() == 200? connection.getInputStream(): connection.getErrorStream();
3. Не стоит забывать про connection.setConnectTimeout(..) и connection..setReadTimeout(..) (в реальных проектах).

Зачем все эти обертки, если можно connection.getOutputStream().write(reqBody.getBytes(StandardCharsets.UTF_8));

И всегда нужно указывать кодировку. Или осознанно не указывать, рассчитывая на кодировку по умолчанию OS или указанную при запуске Java. Но это должно быть именно осознанное решение.

И, хотя, в данном случае, кодировка не принципиальна (текст Ascii), но надеяться на кодировку по умолчанию для Java — не стоит.

\r\n – символ CRLF – вставляет переход на новую строку

Ну нельзя же так. Мир не заканчивается на Windows. Да и сам подход чтения через BufferedReader с записью в StringBuilder ну просто вырвиглаз..

Или это пример под конкретный вызов из под конкретной OS, к конкретному сервису? Типа "оно же работает!"
(предвижу этот аргумент, как ответ на мои замечания).

Не нашел в статье выводы про особенности HttpUrlConnection.
Где например сравнение 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-клиент?