Быстрый старт для ExtJS back-end

[ddosia]

У меня данные на клиент в случае постраничного доступа, а не доступа по id передаются немного в в другом формате, что позволяет сэкономить на повторении названия ключей до двух раз и более.

[MrSLonoed]

Не могли бы дать пояснение как это работает?

[ddosia]

Обычно json данные передаются как {k1:v1, k2:v2}. В случае постраничного доступа ключи всегда одни и те же => передаю список ключей один раз в отдельном поле. Поле deps, это для зависимых сущностей.

[MrSLonoed]

А цель такой модификации в чём? И много ли изменений на стороне клиента?

[ddosia]

цель — избавится от повторения названия ключей, на клиенте все собирается в привычный json элементарно, фу-ия на вход передается два массива одинаковой длинны, в одном список столбцов, во втором список значений, на выходе объект из {k1:v1, k2:v2,… kN:vN}

[MrSLonoed]

Я просто не пойму зачем это нужно, мы получаем лишнее кодирование, декодирование информации, а выигрываем пару сотен байт? Они же не стоят ничего при передаче.

[ddosia]

на моих тестах при 5000 запросах (каждый запрос возвращает 20 записей, у каждой записи по 5 зависимых сущностей) без гзипа размер ответов+запросов+заголовков на моих тестах при обычном способе ~80mb, при моём ~40, гзипом жмет примерно в 4 раза. Так что вроде бы и копейки, но…

[Maxkn]

мне кажется слегка нелогичный дизайн апи. например зачем нужны методы PUT и Delete для example.com/ticket

/users?start=40&limit=20&filter=[{«property»:«name»,«value»:«Вася»}] — такой запрос лучше делать постом, поскольку при большом количестве опций и непонятной их длине — можно легко выйти за лимит гета. да и читаться постом он будет лучше.

на случай если надо послать линк на результат такого запроса — то, мне кажется, логичнее его прихранить в кеше и сгенерить ликн типа /users?filter=kjwhelhelwhiw3WQR. примерно как яндекс со ссылками на карты делает.

рекомендую книгу

ну и просто поизучать REST API известных сервисов.

>Обязательно должно быть поле success
чисто семантически, лучше иметь поле result и оно имеет значение success или error.

[Maxkn]

линк на книгу невставился book.pdfchm.net/restful-web-services-cookbook-solutions-for-improving-scalability-and-simplicity/9780596801687/

[MrSLonoed]

СпасибО!

[ainu]

Согласен, надо запрещать удалять список, чтобы нечаянно не сделать дурного. Не помню, чтобы удаление списка ВСЕХ объектов требовалось, максимум что-то вроде /goods/by_user/12 или что то в этом роде. И то это происходит параллельно с процессом удаления самого пользователя.

[Maxkn]

обновления/удаления лучше всегда делать постом, в том смысле, что параметры не в урле.

на моей практике get всегда должен быть read only.

Как частный прикол: Вася делает урл с удалением чегото и посылает его Пете, с которым они пользуются какимто сервисом. Петя негодует.

[ainu]

А, ну это отдельный разговор, разумеется, через POST. Я про вообще возможность (пусть через POST) удалить список пользователей.

[MrSLonoed]

Я понимаю, что это выглядит не самым лучшим образом. Это всё исключительно для ExtJS. Для ускорения и удобства разработки. Поле succes, id — стандартные в этом фреймворке.

Вот по длине GET спорный вопрос. Конечно плохо иметь ограничение, но я пока ни разу не сталкивался.

[MrSLonoed]

Всё сделано для того, что бы при объявлении модели написать

Ext.define('App.model.Region', {
	extend: 'Ext.data.Model',
	fields: [
		{name: 'name'},
		{name:'id',type:'int'}
	],

	proxy: {
		url: '/regions',

		type: 'rest',
		simpleSortMode : true,
		reader: {
			type: 'json',
			root: 'items'
		},
		writer: {
			type: 'json',
			writeAllFields :true,
			root :"items",
			encode :true
		}
	}
});

И оно будет работать.

[Maxkn]

оно точно также будет работать и в случае если REST интерфейс будет логичным. При всей моей нелюбви к ExtJS с данными он работает на 5