По первой же ссылке из приведенных вами американский вариант /ter/ без звука «шва» после e. Я позже проверю этот нюанс, почему в одних транскрипциях пишется e, в других ɛ. Эти звуки похожие, но разница есть.
С IPA я знаком, но насчет ɒ соглашусь только отчасти. Например, в слове hot в транскрипции тот же звук, но в US English он ближе к а, чем к о — www.wordreference.com/definition/hot (можно прослушать сэмпл). Я в начале статьи указал, что транскрипции и приблизительные русские транскрипции будут ориентированы на US English. Насчет chaos — www.wordreference.com/definition/chaos в этом примере я тоже слышу больше «а» чем «о».
На таком масштабе радикальной разницы не будет. Я так понимаю, подключение не использует SSL, т.е. дополнительные затраты на SSL handshake при установке соединения не идут. Сервер легко выдержит 100 одновременных постоянных подключений, а сдругой стороны — передача данных не настолько частая, чтобы установка соединения вносила какую-то заметную задержку (при условии что канал не настолько плохой, что и 20 байт не всегда быстро доходят, если доходят вообще :)).
В целом, если нет перспективы роста на десятки-сотни тысяч соединений (и даже при такой перспективе тоже могут быть варианты с постоянными соединениями), я бы держал постоянно открытое TCP соединение и по нему бы общался, пересоздавая в случае сбоев.
С DNS можно сразу получить несколько IP, но в общем случае round-robin работает на базе поведения DNS сервера — либо с каждым запросом возвращается другой IP адрес (по кругу), либо возвращается полный список, но каждый раз с разным порядком адресов (https://en.wikipedia.org/wiki/Round-robin_DNS, blogs.technet.microsoft.com/networking/2009/04/17/dns-round-robin-and-destination-ip-address-selection). Я на практике не наблюдал, чтобы HttpClient при работе с доменом, зарегистрированным на несколько IP адресов, сам бы перебирал их с каждым новым подключением.
С точки зрения HTTP протокола, между API, которое возвращает JSON, и обычными страницами, отдающими клиенту HTML, принципиальной разницы нет — это просто разные типы контента. Соответственно, нет и разделения на то, какие типы контента какими классами лучше всего получать. Что выбрать, HttpWebRequest или HttpClient, скорее зависит от удобства, гибкости и производительности который дает каждый их них.
HttpWebRequest очень низкоуровневый, каждый запрос нужно конструировать заново, и на это уходит заметно больше кода, чем на те же действия через HttpClient. При этом, если надо в юнит-тестах сделать мок вместо реальных обращений по сети, то с HttpWebRequest это будет проблематичным: по-хорошему придется вокруг этого класса делать фабрику и в коде использовать ее методы вместо явного создания HttpWebRequest. По сути HttpClient — и есть своего рода фабрика запросов. Она конечно же добавляет своего оверхеда в плане производительности, но для 99% случаев я думаю этим можно пренебречь. В то же время HttpClient значительно упрощает реализацию многих сценариев работы с HTTP и по сути является фасадом к более низкоуровневым классам, таким как HttpWebRequest. Но как и в любой абстракции, в нем есть неявные моменты, которые и описаны в статье.
a set of matching furniture, esp. for one room:a bedroom suite.
А с pause мне такое неизвестно и на странице с wordreference не вижу. Пришлите цитату, пожалуйста.
Я слышал это название от нэйтивов неоднократно.
Насчет звонкости — да, согласен, но решил не усложнять текст. По указанной в том абзаце ссылке правило полностью расписано.
Спасибо!
В целом, если нет перспективы роста на десятки-сотни тысяч соединений (и даже при такой перспективе тоже могут быть варианты с постоянными соединениями), я бы держал постоянно открытое TCP соединение и по нему бы общался, пересоздавая в случае сбоев.
HttpWebRequest очень низкоуровневый, каждый запрос нужно конструировать заново, и на это уходит заметно больше кода, чем на те же действия через HttpClient. При этом, если надо в юнит-тестах сделать мок вместо реальных обращений по сети, то с HttpWebRequest это будет проблематичным: по-хорошему придется вокруг этого класса делать фабрику и в коде использовать ее методы вместо явного создания HttpWebRequest. По сути HttpClient — и есть своего рода фабрика запросов. Она конечно же добавляет своего оверхеда в плане производительности, но для 99% случаев я думаю этим можно пренебречь. В то же время HttpClient значительно упрощает реализацию многих сценариев работы с HTTP и по сути является фасадом к более низкоуровневым классам, таким как HttpWebRequest. Но как и в любой абстракции, в нем есть неявные моменты, которые и описаны в статье.