Комментарии 16
У меня данные на клиент в случае постраничного доступа, а не доступа по id передаются немного в в другом формате, что позволяет сэкономить на повторении названия ключей до двух раз и более.
Не могли бы дать пояснение как это работает?
Обычно json данные передаются как {k1:v1, k2:v2}. В случае постраничного доступа ключи всегда одни и те же => передаю список ключей один раз в отдельном поле. Поле deps, это для зависимых сущностей.
А цель такой модификации в чём? И много ли изменений на стороне клиента?
цель — избавится от повторения названия ключей, на клиенте все собирается в привычный json элементарно, фу-ия на вход передается два массива одинаковой длинны, в одном список столбцов, во втором список значений, на выходе объект из {k1:v1, k2:v2,… kN:vN}
мне кажется слегка нелогичный дизайн апи. например зачем нужны методы PUT и Delete для example.com/ticket
/users?start=40&limit=20&filter=[{«property»:«name»,«value»:«Вася»}] — такой запрос лучше делать постом, поскольку при большом количестве опций и непонятной их длине — можно легко выйти за лимит гета. да и читаться постом он будет лучше.
на случай если надо послать линк на результат такого запроса — то, мне кажется, логичнее его прихранить в кеше и сгенерить ликн типа /users?filter=kjwhelhelwhiw3WQR. примерно как яндекс со ссылками на карты делает.
рекомендую книгу
ну и просто поизучать REST API известных сервисов.
>Обязательно должно быть поле success
чисто семантически, лучше иметь поле result и оно имеет значение success или error.
/users?start=40&limit=20&filter=[{«property»:«name»,«value»:«Вася»}] — такой запрос лучше делать постом, поскольку при большом количестве опций и непонятной их длине — можно легко выйти за лимит гета. да и читаться постом он будет лучше.
на случай если надо послать линк на результат такого запроса — то, мне кажется, логичнее его прихранить в кеше и сгенерить ликн типа /users?filter=kjwhelhelwhiw3WQR. примерно как яндекс со ссылками на карты делает.
рекомендую книгу
ну и просто поизучать REST API известных сервисов.
>Обязательно должно быть поле success
чисто семантически, лучше иметь поле result и оно имеет значение success или error.
Согласен, надо запрещать удалять список, чтобы нечаянно не сделать дурного. Не помню, чтобы удаление списка ВСЕХ объектов требовалось, максимум что-то вроде /goods/by_user/12 или что то в этом роде. И то это происходит параллельно с процессом удаления самого пользователя.
Я понимаю, что это выглядит не самым лучшим образом. Это всё исключительно для ExtJS. Для ускорения и удобства разработки. Поле succes, id — стандартные в этом фреймворке.
Вот по длине GET спорный вопрос. Конечно плохо иметь ограничение, но я пока ни разу не сталкивался.
Вот по длине GET спорный вопрос. Конечно плохо иметь ограничение, но я пока ни разу не сталкивался.
Всё сделано для того, что бы при объявлении модели написать
И оно будет работать.
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
}
}
});
И оно будет работать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Быстрый старт для ExtJS back-end