Comments 24
А таки "Про Катю" очень злая шутка, я сразу и купился =(
Я думаю, минусят именно из-за этого :D
Удалил. Вероятно mannaro прав.
Честно говоря даже не предполагал что из-за шутки будут сливать хороший пост и карму.
Ладно бы откомментировал кто — ты не прав, на самом деле делать надо вот так и вот так.
После вот такой вот фигни никакого желания писать сюда нету, на самом деле.
Честно говоря даже не предполагал что из-за шутки будут сливать хороший пост и карму.
Ладно бы откомментировал кто — ты не прав, на самом деле делать надо вот так и вот так.
После вот такой вот фигни никакого желания писать сюда нету, на самом деле.
>Возраст: 25 лет
>Опыт работы: 14 лет
Пожалуй, тоже напишу, что пишу код с 10 лет :)
А за статью плюс.
>Опыт работы: 14 лет
Пожалуй, тоже напишу, что пишу код с 10 лет :)
А за статью плюс.
Какое отношение к разработке API имеет статическая страница для людей, пусть и приносящая 10 штук?
О да, для больших приложений. Правильная работа с информацией и все такое. Легкое масштабирование. Расскажите-ка лучше, как избежать потери апдейта (т.е. информации) при обновлении одного ресурса двумя клиентами одновременно.
Ну а то, что Вы рассказали — это банальное разделение приложения на слои, причем весьма, весьма посредственное (но это все же лучше, чем пришедшие от пользователя данные после валидации пихать сразу в Монгу).
Извините за сарказм. Считаю, что имею право, так как пишу код с 9 лет :)
Данный подход не имеет смысла для вас, если у вас маленький проект с небольшим количеством компонентов и разработчиков.
О да, для больших приложений. Правильная работа с информацией и все такое. Легкое масштабирование. Расскажите-ка лучше, как избежать потери апдейта (т.е. информации) при обновлении одного ресурса двумя клиентами одновременно.
Ну а то, что Вы рассказали — это банальное разделение приложения на слои, причем весьма, весьма посредственное (но это все же лучше, чем пришедшие от пользователя данные после валидации пихать сразу в Монгу).
Извините за сарказм. Считаю, что имею право, так как пишу код с 9 лет :)
Ура, первый комментарий по теме поста.
Это иллюстрация преимущества контента. Непосредственно к разработке API пример не относится.
Вопрос не достаточно полный что бы корректно ответить. Так же, зависит от информации, которую модифицируем. Приведу несколько примеров. Коль назвали монгу, применимо к ней.
Общее золото в игре. Вместо выборки и установки нового значения мы можем использовать $inc — в таком случае обе операции, не зависимо от порядка, пройдут успешно. Отвечая на вопрос, что же делать если золото ушло в минус после подобной операции — откат софтварной транзакции и вывод информации о недостатке золота.
В случае если это некая статья, на подобии википедии, то тут мы можем применить несколько вариантов.
По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.
Так вот это не просто и не легко, и умеет это не такая большая доля разработчиков на самом деле.
В случае если у вас всё окружение умеет подобное и применяет — это мега круто. Значит вам удалось попасть в общество экспертов.
В чем посредственность — хотелось бы услышать конкретно. Что не так? Как лучше? Я рад учиться, если ошибся где то.
Какое отношение к разработке API имеет статическая страница для людей, пусть и приносящая 10 штук?
Это иллюстрация преимущества контента. Непосредственно к разработке API пример не относится.
Расскажите-ка лучше, как избежать потери апдейта (т.е. информации) при обновлении одного ресурса двумя клиентами одновременно.
Вопрос не достаточно полный что бы корректно ответить. Так же, зависит от информации, которую модифицируем. Приведу несколько примеров. Коль назвали монгу, применимо к ней.
Общее золото в игре. Вместо выборки и установки нового значения мы можем использовать $inc — в таком случае обе операции, не зависимо от порядка, пройдут успешно. Отвечая на вопрос, что же делать если золото ушло в минус после подобной операции — откат софтварной транзакции и вывод информации о недостатке золота.
В случае если это некая статья, на подобии википедии, то тут мы можем применить несколько вариантов.
- Храним историю изменений. Во время отправки текста помимо идентификатора записи указывается номер ревизии, и, в случае если он был изменён, возвращаем неудачу, сохраняя информацию во временное хранилище и показывая актуальные изменения. Вместо прямой выборки данных используем выборку обновлением, с указанием ревизии. Таким образом если документ не выбрался -> были изменения, если выбрался, то он сразу же был помечен новой ревизией.
- Банально храним дату изменения и при отправке изменений указываем от какого времени были эти изменения, в случае несоответствия показываем пользователю изменения и даем возможность решить что делать.
Ну а то, что Вы рассказали — это банальное разделение приложения на слои, причем весьма, весьма посредственное (но это все же лучше, чем пришедшие от пользователя данные после валидации пихать сразу в Монгу).
По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.
Так вот это не просто и не легко, и умеет это не такая большая доля разработчиков на самом деле.
В случае если у вас всё окружение умеет подобное и применяет — это мега круто. Значит вам удалось попасть в общество экспертов.
причем весьма, весьма посредственное
В чем посредственность — хотелось бы услышать конкретно. Что не так? Как лучше? Я рад учиться, если ошибся где то.
По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.
Вот именно это ощущение лично мне и дала Ваша статья. Кэширование? Нет ничего проще! Масштабирование? Легко! Версионирование? Проще простого! В то время как все это — сложные и в общем случае не имеющие универсального и простого решения проблемы. Я, конечно, не говорю об онлайн-Todo листах с тремя сущностями и четырьмя оперциями над ними.
Выше Вы описали, как можно разрулить потерянное обновление. Это ок, но противоречит данному в начале статьи обещанию показать, как масштабирование и пр. будет сделано без вмешательства в само приложение.
В данном случае изменение в любом случае затрагивает клиентскую часть, т.к. клиенту необходимо сообщать о данной ошибке.
Разруливание подобной ситуации к масштабированию имеет косвенное значение. Даже, скорее, это бизнес-задача, а никак не про масштабирование. В пример могу привести wikia — у моей игры есть там неофициальная вики, и люди жаловались о потере одновременных правок. Это реальная проблема была. Даже в таком крупном проекте решена плохо.
Как я уже говорил — в случае оптимизации и разноса по большому количеству серверов пути API будут одни и те же, хотя даже сервера могут находится в разных странах. И вот возврат этой ошибки — как раз сделает API.
Как вы сказали дальше — универсальных решений нет. Именно по этому это уже не легко. Нет универсального решения -> надо подключать мозг.
Я могу написать сотни статей с конкретными юзкейсами. Но мне это не интересно :-) Да и смысла осоьбо не имеет, т.к. каждый новый случай, ваш случай, уже всё равно не в один из них не уложится. Как видишь даже с твоим вопросом я сразу предложил несколько вариаций, в зависимости от контекста. А таких ситуаций бесконечное множество.
Разруливание подобной ситуации к масштабированию имеет косвенное значение. Даже, скорее, это бизнес-задача, а никак не про масштабирование. В пример могу привести wikia — у моей игры есть там неофициальная вики, и люди жаловались о потере одновременных правок. Это реальная проблема была. Даже в таком крупном проекте решена плохо.
Как я уже говорил — в случае оптимизации и разноса по большому количеству серверов пути API будут одни и те же, хотя даже сервера могут находится в разных странах. И вот возврат этой ошибки — как раз сделает API.
Кэширование? Нет ничего проще! Масштабирование? Легко! Версионирование? Проще простого!
Как вы сказали дальше — универсальных решений нет. Именно по этому это уже не легко. Нет универсального решения -> надо подключать мозг.
Я могу написать сотни статей с конкретными юзкейсами. Но мне это не интересно :-) Да и смысла осоьбо не имеет, т.к. каждый новый случай, ваш случай, уже всё равно не в один из них не уложится. Как видишь даже с твоим вопросом я сразу предложил несколько вариаций, в зависимости от контекста. А таких ситуаций бесконечное множество.
API отличается от UI тем, что оно для программ, а не для юзеров.
Вокруг любого более-менее популярного проекта крутится множество пользователей, среди которые встречаются айтишники разных уровней, и всегда найдутся те, кто начинает рисовать свои таблички, статистику и другое. Чем крупнее проект, те больше людей, тем больше шансов, что встретиться приличный или очень мотивированный программист, который напишет свой сайт, выдающий полезную (с точки зрения пользователей) информацию. Такой сайт может выглядеть как угодно и брать информацию любыми доступными способами.
Если вы — владелец проекта, у вас несколько задач.
Задача первая. Если делаете информативный сайт — это лишняя площадка для популяризирования, контроля информации и заработка на той же рекламе, плюс удобный способ продвигания нужнйо вам информации.
Если вы делаете API, то это API, он должен возвращать в идеале не html, а xml/json, и выглядеть может как страничка-визитка с инструкцией по пользованию. Можно получить с него пользу, предоставляя бесплатный и платный доступ с разным функционалом (хотя бы с ограничением нагрузки для бесплатных пользователей). Если у вас крупный проект, вы можете оставить контакты SEO, чтобы с ним могли связаться админы тех порталов, которые смогли подняться на популярности до серьезного уровня, и сотрудничать с ними на индивидуальных условиях.
Я за свою жизнь (да, кодю с 4 класса), успел поадминить 4 игровых проекта, с онлайном от 150 до 100.000, и ответственно заявляю — создатель игрового проекта, не сможет изначально продумать какая информация понадобится пользователям, и как они смогут заюзать фичи и баги игровой механики.
Поэтому сотрудничество с независимыми создателями различных калькуляторов, сайтов статистики, и так далее — крайне полезно и для того, чтобы фиксить баги в балансе и механики, и выдавать отдельную информацию (зато контролируемо), и даже взаимно зарабатывать на таком сотрудничестве.
Даже борьба с ботами может вестись через такое сотрудничество, когда можно договориться с создателем бота об определенном API, через который будут разрешены конкретные операции — это позволяет «правильным» ботам подавить «неправильные» боты на конкурентной основе.
Вокруг любого более-менее популярного проекта крутится множество пользователей, среди которые встречаются айтишники разных уровней, и всегда найдутся те, кто начинает рисовать свои таблички, статистику и другое. Чем крупнее проект, те больше людей, тем больше шансов, что встретиться приличный или очень мотивированный программист, который напишет свой сайт, выдающий полезную (с точки зрения пользователей) информацию. Такой сайт может выглядеть как угодно и брать информацию любыми доступными способами.
Если вы — владелец проекта, у вас несколько задач.
Задача первая. Если делаете информативный сайт — это лишняя площадка для популяризирования, контроля информации и заработка на той же рекламе, плюс удобный способ продвигания нужнйо вам информации.
Если вы делаете API, то это API, он должен возвращать в идеале не html, а xml/json, и выглядеть может как страничка-визитка с инструкцией по пользованию. Можно получить с него пользу, предоставляя бесплатный и платный доступ с разным функционалом (хотя бы с ограничением нагрузки для бесплатных пользователей). Если у вас крупный проект, вы можете оставить контакты SEO, чтобы с ним могли связаться админы тех порталов, которые смогли подняться на популярности до серьезного уровня, и сотрудничать с ними на индивидуальных условиях.
Я за свою жизнь (да, кодю с 4 класса), успел поадминить 4 игровых проекта, с онлайном от 150 до 100.000, и ответственно заявляю — создатель игрового проекта, не сможет изначально продумать какая информация понадобится пользователям, и как они смогут заюзать фичи и баги игровой механики.
Поэтому сотрудничество с независимыми создателями различных калькуляторов, сайтов статистики, и так далее — крайне полезно и для того, чтобы фиксить баги в балансе и механики, и выдавать отдельную информацию (зато контролируемо), и даже взаимно зарабатывать на таком сотрудничестве.
Даже борьба с ботами может вестись через такое сотрудничество, когда можно договориться с создателем бота об определенном API, через который будут разрешены конкретные операции — это позволяет «правильным» ботам подавить «неправильные» боты на конкурентной основе.
Принципиальной разницы кто является клиентом API — пользователь или сторонняя программа, нет, т.к. стороннюю программу так же используют люди.
Дальше часть не очень понятна. В тексте статьи и так сказано что возвращать необходимо требуемыми способами.
В качестве интересного примера с внешней API можно взглянуть на Eve online, для которых делают вплоть до игровых онлайн казино.
В них играют пользователи, но, что бы играть, нужна платная подписка. В итоге сторонние разработчики за бесплатно продвигают твой товар (игру).
Если продолжаем про игры. Можно глянуть, например, Neverwinter. Из браузера ты можешь управлять отправкой помощников на задания. В WOW ты можешь мониторить аукцион. Таких примеров очень много.
Конечно, сразу определить какие действия разрешить — сложно, но вот выдавать ряд информации сразу возможно (например ситуацию на рынке).
Как я уже сказал, это не просто полезно, а приносит деньги владельцем проектов.
Дальше часть не очень понятна. В тексте статьи и так сказано что возвращать необходимо требуемыми способами.
В качестве интересного примера с внешней API можно взглянуть на Eve online, для которых делают вплоть до игровых онлайн казино.
В них играют пользователи, но, что бы играть, нужна платная подписка. В итоге сторонние разработчики за бесплатно продвигают твой товар (игру).
Если продолжаем про игры. Можно глянуть, например, Neverwinter. Из браузера ты можешь управлять отправкой помощников на задания. В WOW ты можешь мониторить аукцион. Таких примеров очень много.
Конечно, сразу определить какие действия разрешить — сложно, но вот выдавать ряд информации сразу возможно (например ситуацию на рынке).
Как я уже сказал, это не просто полезно, а приносит деньги владельцем проектов.
«Принципиальной разницы кто является клиентом API — пользователь или сторонняя
программа»
API — это Advanced Programmer Interface, а не Advanced User Interface или interactive user database access.
Если владелец продукта сам предоставляет онлайн-базу, то это не API, а онлайн база, онлайн статистика. Суть именно в этом — кто подключается — юзер или софт.
программа»
API — это Advanced Programmer Interface, а не Advanced User Interface или interactive user database access.
Если владелец продукта сам предоставляет онлайн-базу, то это не API, а онлайн база, онлайн статистика. Суть именно в этом — кто подключается — юзер или софт.
Ок, поясню.
Если нашим продуктом является, например, сайт.
Пользователь октрыл сайт (SPA), браузер делает запрос к API и выводит данные. Как бы это настолько очевидно что не пользователь лично делает этот запрос, что мне казалось излишнем подобное комментировать.
Если нашим API воспользовался сторонний разработчик — он либо получил данные к себе, либо вывел их в приложение конечному пользователю. Так или иначе пользователь увидел в продаже нужный ему чайник и купил его. У вас или через партнёра — деньги вы имеете в любом случае.
Если нашим продуктом является, например, сайт.
Пользователь октрыл сайт (SPA), браузер делает запрос к API и выводит данные. Как бы это настолько очевидно что не пользователь лично делает этот запрос, что мне казалось излишнем подобное комментировать.
Если нашим API воспользовался сторонний разработчик — он либо получил данные к себе, либо вывел их в приложение конечному пользователю. Так или иначе пользователь увидел в продаже нужный ему чайник и купил его. У вас или через партнёра — деньги вы имеете в любом случае.
API запрос и HTTP запрос отличаются тем, что в случае API запроса, программа получает данные, с которыми она работает.
В случае HTTP запроса, выдается html страничка, которая рассчитана на то, что ее будет глазами смотреть пользователь. И чтобы программно можно было обработать данные из html странички, ее нужно парсить.
В общем тут нет смысла спорить, если вы не понимаете сути термина API
В случае HTTP запроса, выдается html страничка, которая рассчитана на то, что ее будет глазами смотреть пользователь. И чтобы программно можно было обработать данные из html странички, ее нужно парсить.
В общем тут нет смысла спорить, если вы не понимаете сути термина API
Что-то вы перепутали мягкое с желтым.
API запрос может идти через HTTP.
HTTP это протокол передачи данных, а какие там уже данные — вопрос третий.
API запрос может идти через HTTP.
HTTP это протокол передачи данных, а какие там уже данные — вопрос третий.
«какие там уже данные — вопрос третий»
Не верно, это собственно главный вопрос. Ну оговорился с HTTP, знаю я что это такое. Но зачем сразу хвататься за слово? Мы обсуждаем термин API.
API запрос может идти вообще по чем угодно. Смысл термина в том, что API запрос возвращает данные не в human-friendly виде.
Не верно, это собственно главный вопрос. Ну оговорился с HTTP, знаю я что это такое. Но зачем сразу хвататься за слово? Мы обсуждаем термин API.
API запрос может идти вообще по чем угодно. Смысл термина в том, что API запрос возвращает данные не в human-friendly виде.
HTML это тоже не human-friendly вид.
В human-friendly его превращает браузер.
HTML является частным случаем XML. С данными в XML вопросов же нет, да? JSON тоже самое, в принципе.
Разница в том, что HTML содержит дополнительную служебную информацию.
Повторюсь — нет никакой принципиальной разницы в каком формате у нас возвращаются данные.
Если убрать из HTML всю служебку мы получим чистый контент разбитый семантически на логические блоки, который мы ровно точно так же можем распарсить в то, что нам требуется.
По факту парсинг JSON, XML, HTML или чего-либо отличается только наличием библиотек или встроенных инструментов.
В human-friendly его превращает браузер.
HTML является частным случаем XML. С данными в XML вопросов же нет, да? JSON тоже самое, в принципе.
Разница в том, что HTML содержит дополнительную служебную информацию.
Повторюсь — нет никакой принципиальной разницы в каком формате у нас возвращаются данные.
Если убрать из HTML всю служебку мы получим чистый контент разбитый семантически на логические блоки, который мы ровно точно так же можем распарсить в то, что нам требуется.
По факту парсинг JSON, XML, HTML или чего-либо отличается только наличием библиотек или встроенных инструментов.
>>>Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?
Вы так и не рассказали, каким образом страница, на которой один только текст (который, очевидно, доступен всем и бесплатно) и нет графики (что, видимо, означает отсутствие рекламы) вообще приносил какие-то деньги.
>>>Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.
И что? Сам по себе pagerank не может приносить деньги. Был какой-то элемент (реклама, руководства за деньги, уроки), который и позволял зарабатывать. Какой?
Вы так и не рассказали, каким образом страница, на которой один только текст (который, очевидно, доступен всем и бесплатно) и нет графики (что, видимо, означает отсутствие рекламы) вообще приносил какие-то деньги.
>>>Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.
И что? Сам по себе pagerank не может приносить деньги. Был какой-то элемент (реклама, руководства за деньги, уроки), который и позволял зарабатывать. Какой?
Может быть как-нибудь напишу статью «Как обрабатывать миллион одновременных геораспределённых соединений и не обосраться» с конкретными примерами, когда NDA закончится и настроение будет.
Sign up to leave a comment.
Вы зарабатываете на информации (зачем нужен API и как его грамотно спроектировать)