Drovosek01

Вероятно эта утилита неправильно интерпретирует данные SMART. Очевидно цифры это мегабайты, а не гигабайты.
200террабайт за два месяца ваш компьютер физически не сможет записать.
Попробуйте CrystalDiskInfo

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

Есть и другие подходы к архитектуре распределенных приложений, например архитектуры, основанные на RPC (удаленный вызов процедур). Информация в таких архитектурах также представлена в виде некоторого набора сущностей, однако операции над ними определяются конкретной задачей, и для каждой сущности будет свой набор. Это больше соотвествует классическому ООП-подходу. Таким образом, RESTful следует подходу много сущностей (ресурсов) - мало операций (и эти операции известны заранее), а RPC - немного сущностей, но много операций над ними.

Также важной чертой REST является отсутствие состояния, сохраняемого между запросами к ресурсам. Это очень важно для масштабирования системы.

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.

Вам нужно определить, какая сущность главная, а какая второстепенная для вашей программы. Как это будет выглядеть? Сначала заводится список тренеров а потом к ним крепятся команды? Или, наоборот, есть список команд и нужно создать им тренера? А может, это равнозначные сущности, и вы хотите иметь возможность завести список команд и список тренеров независимо друг от друга, а уже потом проставить связи?
Ставьте внешний ключ той сущности, которая не будет иметь множественной связи с большей вероятностью.
К примеру, если это соц сеть для тренеров, то вероятнее всего, тренер сможет добавлять список команд которых он тренировал. И тогда trainer_id пригодится в teams.
Но если ваша соцсеть вырастет и там будет база команд, которые тренер сможет выбрать из выпадающего списка (т.е. у команд тоже может быть много тренеров), то придется делать M:N. Ваш случай связи 1:1 возник только потому что ваше приложение еще недостаточно развилось.

Также не забудьте что 1 к 1 реализуется назначением UNIQ ограничения на внешний ключ. Иначе это 1 ко многим.

Drovosek01, то как Вы написали веб сервер не годится для реальных задач. Вам легче и лучше было бы переписать сервер используя библиотеку или фреймворк (bottle, falcon, flask, ...). Но если целью стоит изучение работы сокетов, то:

1. Ваш сервер однопоточен и блокируемый. Причина может крыться в этом, т.к. браузер вполне может соединяться с веб сервером параллельно в несколько потоков. Посмотрите примеры неблокируемого режима сокет сервера и/или используйте нити (threads). Если будет сложно, как я и писал переходите на высокоуровневое программирование.
   
2. Причина остановки может быть пассивное закрытие сокета из за TTL к примеру. Проверяйте работы сокетов не на высоком уровне(Chrome), а на низком используя WireShark. Т.к. у Вас не отлаженный низкоуровневый код.
   
3. И по поводу возможного TTL, способ которым Вы создаете страницу, уж простите, ужасный. Хотя бы перепишите возврат шаблонов в таком виде:

   def index():
       with open(os.path.join(dir,'templates/index.html'), encoding='utf-8') as template:
           buffer = template.read()
       while True:
          yield buffer

   Чтение с диска на кажде соединение, даже если у Вас SSD, это как то черезчур там более в таком простом случае
   

В версии 1.11 поддерживают совместимость с IE6-8. В версиях 2.* от поддержки старых IE отказались. По функциям они одинаковые, просто версия 2.* немного легче из-за вырезанного кода.

Потому что %20 это код пробела

Зайти в консоль разработчика, выбрать вкладку Network, поставить галочку Preverse log, отправить сообщение и смотреть результат.

Столко слов вместо одного поискового запроса?
https://stackoverflow.com/questions/48480118/how-d...

Одно или два двоеточия?

Нет никакой разницы между :before и ::before или между :after и ::after. Синтаксис с двумя двоеточиями характерен для CSS3.

На www.w3.org/TR/css3-selectors/#pseudo-elements есть такой абзац:

Этот знак (::) введен для того, чтобы отличить псевдо-классы от псевдо-элементов. Для совместимости с уже существующими таблицами стилей псевдо-элементы в CSS 1 и 2 также возможно задавать с одним двоеточием (в частности, :first-line, :first-letter, :before и :after

источник