Виктор Борисов

Основной посыл использования 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 в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

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

Java. Потом можно писать под что угодно. Java более популярный язык программирования и самый главный плюс - возможность разработки под Android.

Java- более популярен и функционален, чем Питон.

Плюсану джаву. Популярнее, так что после базового изучения будет проще устроиться куда-то джуном и там уже набираться опыта на реальных проектах. Статическая типизация дисциплинирует, на начальном этапе это важнее, чем возможность писать более лаконичный код. В мире джавы более заморочены на архитектуре и паттернах, быстрее придёт понимание этих вещей, а это пригодится в дальнейшем независимо от того, на чём будете писать. Шире выбор направлений развития: веб, десктоп, андроид, бигдаты всякие. Ну и тупо средняя температура по больнице зарплата выше :)

Их не пишут, нельзя вот так вот взять и написать yotube.
Во первых не стоит называть такие проекты сайтами. Сайт это просто аккуратно оформленная страничка с данными доступная по протоколу http.
Т.е вордовский документ размещенный в сети интернет это и есть сайт.

А то что вы назвали - vk.com, imhonet, youtube это не сайты.
Это программно аппаратные комплексы.
Т.е нужны сервера, датацентры размещенные в ключевых точках, нужна система обеспечивающая взаимодействие этих серверов.
Это продукт труда множества системных администраторов, программистов, инженеров, электриков, маркетологов, и.т.д..

Лутца обязательно. Это лучшие книги по Python на русском.
Потом по Django лучше всего с djbook.ru

Внесу свои 5 копеек, с курса 1го работаю(не только программистом):

Всем привет! Я студент, учусь на втором курсе. До недавнего времени плыл по течению, просто хорошо учился в инсте (т.е. есть только опыт написания простых прогармм на Дельфи), сейчас же финансовое положение в семье заставило задуматься о своём будущем.

Как бы избито это не звучало, но забудь подходы к программированию, которые у тебя были в ВУЗе, тот опыт полезен, но пока его придержи. Начни с освоения контроля версий, разберись с пакетами, зависимостями, привыкай перед тем как приступить к задаче, сначала исследовать - никто ли до тебя не занимался ли решением такой же задачи? В общем старайся максимально использовать чужой код, анализировать его, смотреть с какими проблемами сталкивались люди при его написании и т.д. И старайся писать понятный, не только тебе, код.
Анализ чужого кода - важная, недооценённая студентами, составляющая работы.

Начал изучать Питон (взял на курсере "Intro to interactive programming in Python", сейчас перехожу ко второй его части), т.к. он используется в DSP и компьютерном зрении, а мне эти области интересны. Также полезной вещью в моём багаже будет MySQL, который у меня сейчас идёт в универе.

Питон относительно спорное начинание. Да, в перспективе - он хорош, но, субъективно, найти работу на PHP без коммерческого опыта - проще(это если финансовое положение такое что надо вот сейчас найти работу). Спрос большой, ровно как и спектр задач. Когда в голове будет понимание спектра задач для языка и вообще того какие задачи возникают в коммерческой разработке, тогда уже можно примерять Python к тем задачам которые перед тобой стояли.
Если есть время(3-6 месяцев) то можно подучить джангу/фласк(только что-то одно) и идти работать стажёром - бесплатно или же помогать в open source(тут как раз и поймёшь примерные задачи, которые будут вставать перед тобой в работе, потому как туториалы хорошо, а реальность отличается).
Не знаю как у вас дают БД, у нас давали так себе, поэтому лучше дотягивай сам, хотя бы то как язык работает с базой.
Если хочешь научное - компьютерное зрение и т.д., устраивайся на кафедру (вариант с натяжкой - работу где у тебя будет много свободного времени(сторож, продавец простаивающий)) и штудируй литературу пачками, т.к. минимальные требования там высокие и нужно больше фундаментальных знаний, нежели знания ЯП. Плюс ко всему - участие во всех олимпиадах по программированию, интересные курсовые работы, по актуальным темам.

Среднесрочную задачу я перед собой поставил конкретную: через год устроиться на оплачиваемую стажировку, чтобы начать получать хотя бы какие-то деньги и опыт. Поэтому вариант с поступлением в ШАД, который я изначально рассматривал как основной, отпал, и я решил перенести эту затею на год вперёд.

На год вперед после работы? Потому как ШАД+оплачиваемая стажировка+учеба = ничего. Нигде не будешь успевать. По большому счёту - не ШАДом единым, если год самообучения, плюс год работы, то лучше включить в эти 2 года ещё и изучение того что проходят в ШАД, чтобы быть подкованнее

В итоге у меня вопрос: что посоветуете сделать/изучить? Сконцентрироваться на Django, мб html/css, и т.п. и гарантированно идти стажироваться в заданный срок? Или рискнуть, попробовать делать то, что интересно (изучить dsp на базе питона, либо opencv), и податься в какое-нибудь крутое место типа Яндекса, в надежде, что на тебя обратят внимание? (Наиболее туманный для меня вариант). Ещё недавно возникла идея попробовать себя в связке веба, и, например, машинного обучения, может тоже неплохо? В общем, помогите советом нубу)

Выше писал. Тут стоит оценить риски и ситуацию в семье. В принципе, если попадётся хороший руководитель и ты сможешь его убедить цифрами что машинное обучение принесёт пользу бизнесу, то сможешь совместить и связку веба и машинное обучение, плюс подтянуть курсовые и дипломные на эту тему(заработать миллон долларов, прославиться, написать свой язык программирования)
P.S. Не выпускник ШАДа, обычный человек-программист

Django - это эдакий комбайн, альтернатива Rails для Python. Соответственно из его философий - это простота и функциональность, дисциплина и модульность, удобство и производительность. Получается у него это весьма не плохо. Хотя есть свои моменты, не самые приятные, скажем так.
Если по поводу Python, то здесь неплохо подходят такие слова, как простота, лаконичность, скорость. В некотором смысле удобство. Порой, хотя это и официально скорее возбраняется, есть такая неприятная особенность, как write only, то есть пишется код легко и просто, но через пару лет прочитать его будет весьма сложно.
Ну и потом, Python - Generic Purpose Language, то есть он всё таки предназначен для всего, а не в основном для вэба. Порой это видно. Например, на его основе нет нормального сервера, нет нормальной поддержки https. И в то же время, он один из немногих (хотя сегодня это почти не так), неприемлит cgi-bin.
К слову, хочу обратить внимание, на такой фреймворк, как Flask. Он пока не очень быстрый, зато лёгкий и очень модульный. К тому же на нём легко писать.

softwaremaniacs.org/blog/2005/12/08/django Тут достаточно неплохо описаны некоторые идеи.
Я так понимаю, Вас больше беспокоят дополнительные приложения.
В идеале, проект Django состоит из некоторого числа независимых приложений, каждое из которых отвечает за свою часть во всем проекте (В блоге, например, отдельные приложения для постов, комментариев. И еще много других, о которых сейчас даже трудно задуматься: например, thumbnail для выдачи миниатюр аватарок пользователей и др.). Каждое такое приложение должно быть настолько независимым, что при желании можно совершенно безболезненно перенести его в другой проект. Достаточно подключить его в INSTALED_APPS и можно пользоваться. Эта идея достаточно практична: на сайте https://www.djangopackages.com/ можно найти приложения для решения почти любой повседневной задачи и не только.
Конечно, в целях практики, стоит попытаться самому реализовать приложения, желаемого проекта. С каждым новым проектом вы будете начинать понимать, какие части прошлых проектов стоит выделить в отдельные приложения, чтобы не приходилось копипастить код, тем самым применяя принцип DRY.
P.S. А начать изучать Django стоит с уроков из документации. Там и практика и разъяснение принципов.