Комментарии 8
Для работы с rest в django есть еще одно не плохое приложение именуемое как django-piston.
Одним из самых популярных для этих целей является django-tastypie.
Благодарю, обязательно расмотрю.
да, тоже смотрел в сторону tastypie, плюс легко интегрировать с backbone)
А есть полно всяких интересных решений. На самом деле есть из чего выбирать.
Я просто был удивлен что тут написали только о django-piston и djangjo-rest-framework, а про самый популярный, и наиболее часто используемый django-tastypie ничего не сказали)
Я просто был удивлен что тут написали только о django-piston и djangjo-rest-framework, а про самый популярный, и наиболее часто используемый django-tastypie ничего не сказали)
Недавно тут упомянули REST, заинтересовался для своего проекта — а тут и эта статья подкатила)
Если это всё относится только к Python + Django, то и назвали бы пост соответственно… Спасибо.
Самая большая проблема состоит в том, что подобная схема не позволяет хранить модели заведомо неизвестной длинны. Это, правда, ограничение реляционной базы данных, а не выбранной связки. Такие API я отношу к «внутренним», т.к. таким, которые можно использовать для своих же приложений.
Питон, благодаря универсальным функциям (def foo(*args, **kwargs)) позволяет обрабатывать сколь угодно сложные вложенные последовательности. Другие дело, что они не перекладываются на структуру реляционных баз. Зато на Key-Value NoSQL-хранилища — за милую душу. Например на MongoDB. Для Django даже есть backend. Т.е. можно будет написать некоторую универсальную модель, которая будет принимать на вход последовательности произвольной вложенности. И спокойно класть их в базу.
Кроме того, замечательно когда можно описывать модели данных вне моделей django. Это очень упрощает доработку и изменение схемы данных для API. Особенно если это делать в замечательном формате, который вы и используете — yaml.
Питон, благодаря универсальным функциям (def foo(*args, **kwargs)) позволяет обрабатывать сколь угодно сложные вложенные последовательности. Другие дело, что они не перекладываются на структуру реляционных баз. Зато на Key-Value NoSQL-хранилища — за милую душу. Например на MongoDB. Для Django даже есть backend. Т.е. можно будет написать некоторую универсальную модель, которая будет принимать на вход последовательности произвольной вложенности. И спокойно класть их в базу.
Кроме того, замечательно когда можно описывать модели данных вне моделей django. Это очень упрощает доработку и изменение схемы данных для API. Особенно если это делать в замечательном формате, который вы и используете — yaml.
MongoDB — это не kv-хранилище, а документо-ориентированное.
NoSQL — это не более, чем маркетинговое название всех хранилищ (и баз данных в целом), в которых, если высказаться грубо, нет «сложного» sql (на самом деле, not only sql, хотя я практически присутствовал во время, когда nosql всплыл как нечто, что не более, чем очередной интернето-твиторо-мем): иерархические, документо-, объектно-ориентированные (но тут возможет страшный OQL), те же kv.
Опять же, никто не запрещает использовать те же mysql/postgresql/anysql как k/v хранилища. Индексируйте данные модным elasticsearch'ем и получайте их по ключу «select * from table where id = ?» (или и вовсе пройдите за пачкой данных напрямую в хранилище).
Хипсторство не ра-бо-та-ет, если вы не понимаете, для чего оно вам нужно.
А я, в свою очередь, вижу общую путаницу на тему БД, СУБД, SQL, NoSQL, KV, документо-ориентированные и хипста-ориентированные хранилища, базы дынных и систем управления базами данных. Что, в целом, меня немного расстраивает.
Проблемы, с которым сталкивается человечество при разработке архитектуры данных начинаются где-то около твитора или фейсбука — это многочисленные счётчики (замена update на append-only + моментальная агрегация), различные ссылки объектов туда-сюда, друг на друга, етц, в следствие возникают проблемы с расширяемостью, придумывают map-reduce и аналоги. И решают эти задачи отнюдь не на дедике в hetzner.net, а на, как минимум, десятке таких.
Глянуть на тот же достаточно взрывной Pinterest:
— Март 2010: MySQL
— Январь 2011: MongoDB
— Весна-лето 2012: MySQL — по сей день
На этом внезапно закончу, а то потянуло на графоманство. Думаю, Вы поняли о чём я :-)
NoSQL — это не более, чем маркетинговое название всех хранилищ (и баз данных в целом), в которых, если высказаться грубо, нет «сложного» sql (на самом деле, not only sql, хотя я практически присутствовал во время, когда nosql всплыл как нечто, что не более, чем очередной интернето-твиторо-мем): иерархические, документо-, объектно-ориентированные (но тут возможет страшный OQL), те же kv.
Опять же, никто не запрещает использовать те же mysql/postgresql/anysql как k/v хранилища. Индексируйте данные модным elasticsearch'ем и получайте их по ключу «select * from table where id = ?» (или и вовсе пройдите за пачкой данных напрямую в хранилище).
Хипсторство не ра-бо-та-ет, если вы не понимаете, для чего оно вам нужно.
А я, в свою очередь, вижу общую путаницу на тему БД, СУБД, SQL, NoSQL, KV, документо-ориентированные и хипста-ориентированные хранилища, базы дынных и систем управления базами данных. Что, в целом, меня немного расстраивает.
Проблемы, с которым сталкивается человечество при разработке архитектуры данных начинаются где-то около твитора или фейсбука — это многочисленные счётчики (замена update на append-only + моментальная агрегация), различные ссылки объектов туда-сюда, друг на друга, етц, в следствие возникают проблемы с расширяемостью, придумывают map-reduce и аналоги. И решают эти задачи отнюдь не на дедике в hetzner.net, а на, как минимум, десятке таких.
Глянуть на тот же достаточно взрывной Pinterest:
— Март 2010: MySQL
— Январь 2011: MongoDB
— Весна-лето 2012: MySQL — по сей день
На этом внезапно закончу, а то потянуло на графоманство. Думаю, Вы поняли о чём я :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Web API с помощью Django REST framework