19:22 

Юрий Рэйн
λOther side of the memory crystal. …λ
Добрый вечер!
Скажите пожалуйста, по какой причине были приняты решения при создании API, котрые признаться меня ставят в тупик:
1) Кодировать число как строку
2) Отказаться от JSON массивов и создать каждому посту ключа (который соответствует id поста, например).
Т.е. вместо {"count":8, "posts": [{},{}]} выбрать вариант, требующий более сложного разбора: {"count":"8", "posts": {"0": {}, "1":{}, }}

@темы: Тип: Предложение, Тип: Неудобство, Тип: Вопрос

Комментарии
2015-01-07 в 11:59 

gluker
очень_очень_очень_много_букв_ без_пробелов
да нет никаких сложностей:



зато имея такую структуру мы можем ее сохранить в кэш и потом выбирать сохраненные записи без дополнительного запроса например при переходе на страницу комментов:


2015-01-07 в 15:13 

Юрий Рэйн
λOther side of the memory crystal. …λ
gluker,
По поводу чисел отчасти проблема снимается, но благодаря разработчикам JSON парсера, предусмотревшим такой вариант. (Писать свой парсер - конечно полезно, но вот использовать подобные велосипеды стоит с осторожностью.)

В таком варианте нет. (Кстати, какой язык в приведённых примерах? JS? Похож, но как его тогда предлагается использовать с API?)
При использовании Python ещё можно жить, но код на нём специфичен для распространения конечным пользователям. Однако при использовании других языков: C#, Golang , особенно с желанием минимизировать использование сторонних библиотек получается я уже не могу использовать приёмы вида:


Поскольку не могу предсказать количество элементов posts. Таким образом надо преобразовывать в Dictionary и постоянно следить за преобразованием типов (Вопрос: Оно того стоит?). Можно конечно часть логики вынести в браузер

2015-01-17 в 13:42 

gluker
очень_очень_очень_много_букв_ без_пробелов
(Кстати, какой язык в приведённых примерах? JS? Похож, но как его тогда предлагается использовать с API?)
--------
да это js
использовать например так: diary.ru/m1
использование Dictionary в c# абсолютно нормальная практика, если нет большого желания возиться с жесткой типизацией можно использовать тип dynamic
вообще вариантов реализации множество, уже реализован такой, в чем-то он неудобен в чем-то вполне себе, существующий апи уже используется и достаточно давно и плотно, а следовательно вот так просто взять и поменять нельзя

   

@API

главная