Вы зарабатываете на информации (зачем нужен API и как его грамотно спроектировать)

    Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
    Информация — основа любого приложения или сервиса.



    Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?

    Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.

    Цель вашего приложения, какое бы оно ни было — донести (получить, обработать) некоторую информацию до пользователя.
    Интернет магазин: информация о товаре, способы приобретения и доставки.
    Даже если это будет ужасный, некрасивый и неудобный сайт, пользователи всё равно найдут тот товар, который искали. Особенно, если вы торгуете чем-то достаточно уникальным (хотя бы в вашем регионе). Плюс поисковики вам помогут, выводя пользователя сразу к нужному товару.

    Конечно, конверсия может быть ниже, или пользователь может быть не очень доволен опытом работы с сайтом, но, если сам товар будет именно тем, что он искал — всё остальное будет малозначимо.

    Я не рассматриваю магазины, продающие «на эмоциях», и покупки, о которых пользователь может потом пожалеть.

    Многопользовательская онлайн игра: информация об игроке, друзьях и окружающем его мире
    Примеры могут варьироваться в зависимости от жанра и других параметров, но в целом пользователя интересуют такие вещи, как история мира, переписка/общение с союзниками, информация о текущих событиях, информация об его персонаже/деревне/корабле/чем-угодно-другом.

    Очень часто способ доступа к этой информации уходит за пределы самого клиента игры. С помощью мобильного приложения можно проверить, не нападает ли на тебя кто, или выставить какие-нибудь товары на внутриигровой аукцион, даже не заходя в саму игру.

    Музыкальный стриминговый сервис — мета-информация + музыкальные файлы
    Пользователь хочет найти интересующую его музыку. Все обёртки, умные очереди, лицензионность и прочая шелуха мало кого интересует.

    Конечно, хорошо использовать лицензионный контент, но если пользователь не может найти то, что искал — он уйдет и найдет это в другом месте. В интернете люди не запоминают информацию как таковую, они запоминают место, где эту информацию нашли. Поэтому, если на вашем сайте нет песен группы Х, но зато есть ссылка на страницу группы Х, где они продают свои альбомы, ваш сервис все равно в плюсе, потому что пользователь запомнил, где он взял информацию о группе Х и вернется к вам еще раз поискать информацию о группе Y.

    Я работал в нескольких музыкальных проектах, и очень часто всё упиралось именно в наличие необходимых треков, несмотря на десятки терабайт данных.

    Видео-сервис — видеозаписи
    В какой-то момент youtube набрал критическую массу видеозаписей и стал лидером рынка. У них был не самый удобный сайт, не самые лучшие условия. Вообще многое было не так, но именно обилие контента привлекало посетителей, и как следствие, контента становилось только больше.


    Думаю, идею вы уже уловили. Примеры можно приводить бесконечно (вот ещё один: на википедию не за дизайном ходят. Более того, часть информации с википедии выводится сразу в поисковой выдаче, без открытия даже самого сайта), и если думаете, что в вашем случае это неприменимо — напишите в комментариях (или на почту / в личку), и я объясню, почему всё же применимо.

    Так вот: чем бы вы ни занимались, первичной всегда будет информация. Хорошую, качественную информацию пользователи обязательно найдут и обратятся к вам.

    Я расскажу, как организовать работу с информацией так, чтобы это было:
    1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
    2. Удобно для пользователей — легко документировать, понятно как использовать.
    3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.

    Данный подход не имеет смысла для вас, если у вас маленький проект с небольшим количеством компонентов и разработчиков.



    Оглавление:
    1. Потребители информации
    2. Как работать с информацией (API)
    3. Внутренний слой API
    4. Внешний слой API
    5. Оптимизация тяжелых запросов
    6. Пользователи
    7. Масштабирование
    8. Кэширование
    9. Версионирование
    10. Итог


    Допущения / недостаток информации
    В тексте статьи я использую ряд допущений: например, что у вас уже что-то имеется или реализовано.

    Практически в каждый из вопросов можно углубляться бесконечно, по объему подробный разбор тянет на целый цикл подобных статей. Если какая-то информация не была указана — я посчитал, что для восприятия концепта она не важна.

    Если считаете, что всё же чего-то не хватает — пожалуйста, сообщите, и статья будет дополнена в соответствии с пожеланиями.



    Потребители информации


    Потребителей информации можно разделить на две категории — внутренние и внешние.

    Внутренние — это ваши же продукты и сервисы. Разница в том, что для «своих» API может предоставлять гораздо более широкий функционал с меньшими ограничениями. Например, те же карты гугла на собственном домене могли работать с применением webgl, и как следствие, значительно быстрее, а встраиваемые — нет (на текущий момент ситуация могла измениться, не проверял).

    Внешние — конечные пользователи или продукты, не принадлежащие вашей компании. Например, для карт гугл вы являетесь внешним пользователем. Обычно доступ к информации извне сильно ограничен, и часто требуются специальные ключи доступа.


    Как работать с информацией?


    Для работы с информацией мы будем предоставлять web API. Реализовывать будем 2 слоя (внешний и внутренний). Слой подразумевает, как минимум, отдельное приложение.

    Зачем нужен API?

    API позволяет предоставлять данные в платформонезависимом виде. Не всегда известно, каким образом и где будут использоваться данные, и разработка API — хороший способ заявить «у нас есть информация — обращайтесь к нам».

    Все примеры кодов — лишь один из многих вариантов реализаций. Это обеспечит возможность использования данных независимо от способов реализации конечного продукта (включая оффлайн приложения, при условии хотя бы единовременного выхода в сеть).

    В первую очередь необходимо описать модели и коллекции данных. В случае если приложение реализуется на Javascript (nodejs на сервере), появится возможность использовать одни и те же модели и на клиентах, и на серверах.

    Модель — описание некоей сущности (например, музыкальный трек): её поля, их свойства, способы доступа и предоставления информации. Модель может дублировать схему базы данных, но также может расширять её дополнительной информацией. Более того, модель может содержать информацию из нескольких таблиц/коллекций и представлять её как одну сущность. На сервере модель должна быть расширена описаниями по работе с таблицами, доступами к серверам и так далее. На клиенте модель расширяется адресами доступа к данным.

    При обращении к данным модель может содержать также дополнительную метаинформацию о самом запросе (время выполнения, позиция записи в базе, связи), виртуальные поля (например, если в базе хранится path — относительный путь до файла, можно добавить виртуальное поле url, которое будет вычисляться «на лету»).

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

    Примеры будут на Javascript, однако всё описанное применимо к любому языку. Я делал подобные вещи также на php, python и c++. Всё необходимо варьировать в зависимости от размеров проекта.


    Model.extend('Track', { // Название модели
    	attributes: {
    		id: 'integer', // Поле и его тип
    		title: 'string',
    		url: 'string', // Ссылка/путь до файла
    		duration: 'integer',
    
    		album: 'app.model.Album.model', // Связь с другими моделями
    		artist: 'app.model.Artist.model'
    	}
    })
    


    Проверка корректности данных (валидация)
    Чтобы не захламлять код, я опущу подробные описания проверок в примерах. При желании можно указывать любое количество критериев, тексты ошибок валидации и т.п.Валидация применима как на клиентах, так и на серверах.

    Один пример:
    Model.extend('Track', {
    	attributes: {
    		...
    		title: {
    			type: {
    				value: 'string',
    				errorText: 'Должнен иметь тип «Строка»'
    			},
    			required: {
    				value: true,
    				errorText: 'Поле обязательно для заполнения'
    			},
    			length: {
    				min: 5,
    				max: 32,
    				errorText: 'Длинна поля должна быть от 5 до 32 символов'
    			}
    		}
    		...
    	}
    })
    



    Коллекция — набор сущностей (обычно одинаковой природы, то есть, к примеру, музыкальные треки). Набор данных также может содержать дополнительные, относящиеся к самому набору, данные. В качестве метаинформации может быть представлено количество выбранных треков, количество оставшихся (не выбранных) треков, номер страницы, количество страниц. Виртуальным полем может быть общая продолжительность всех треков.

    Model.List.extend('Track.List', { // Название коллекции
    	attributes: {
    		duration: 'virtual' // Виртуальное поле, вычисляется в момент запроса
    	}
    }, {
    	duration: function(tracks) { // Вариант реализации виртуального поля
    		return _.reduce(tracks, function(totalDuration, track) {
    			return (track.duration || 0) + totalDuration;
    		})
    	}
    })
    



    Внутренний слой API


    Этот слой будет доступен только нашим продуктам.

    Так как наши модели уже содержат много информации, мы можем предоставить доступ к данным, используя минимальное количество кода.

    Расширение моделей
    Расширяем модель на сервере и клиенте, описывая название и путь. Общие реализации методов findOne, update, destroy и create описаны в абстракции модели и не требуют отдельной реализации, если принципиально не отличаются.
    Model.extend('Track', { // 
    	findOne: 'GET /track/{id}', // Найти один трек по уникальному идентификатору
    	update:  'PUT /track/{id}', // Обновить изменённые поля
    	destroy: 'DELETE /track/{id}', // Удалить из базы
    	create:  'POST /track' // Добавить новый трек
    })
    


    Расширяем модель только на сервере:
    Model.extend('Track', {
    	'GET /track/top/today': function() { // Возвращает лучший трек за сегодня
    		var track = ...;
    		...
    		return track;
    	}
    })
    


    Расширяем модель только на внутреннем клиенте:
    Model.extend('Track', {
    	findTodayTop: 'GET /track/top/today'
    })
    


    Model.extend('Track.List', {
    	findByArtistId: 'GET /track/byArtistId/{artist_id}' // Найти все треки, принадлежащие указаному артисту
    })
    



    На этом слое мы имеем максимальную гибкость запросов.

    Пример запроса и ответа
    app.model.Track.List.findByArtistId({
    	format: 'json',
    	artist_id: 20974,
    	fields: [ // Поля, которые хотим получить в запросе
    		track, // Все поля основной модели
    		track.artist, // Все поля связанного музыканта
    		track.album.name // Название альбома, в который входит данный трек. Без других полей.
    	],
    	offset: 5, // Пропускаем первых 5 записей
    	limit: 10, // Получаем не более 10 записей
    	sort: [
    		'track.title': 'ASC' // Сортируем треки в алфавитном порядке
    	],
    	cache: 1800 // Кэшируем на стороне клиента на полчаса
    })
    


    В ответ получаем что-то типа:

    {
    	"result": {
    		"tracks": [
    			...,
    			{
    				"id": 856, // Все собственные поля модели
    				"title": "Великолепный трек",
    				"url": "/какой/то/путь/до/трека",
    				"duration": 216,
    				"artist": {
    					"id": 20974,
    					"title": "Великолепный музыкант",
    					... // остальные поля
    				},
    				"album": {
    					"name": "Великолепный альбом" // только имя
    				}
    			},
    			...
    		]
    	},
    	"offset": 5, // Отступ
    	"count": 7, // Выбрано сейчас
    	"totalCount": 12 // Всего найдено
    }
    


    Не обязательно именно так вкладывать информацию. Если боитесь дубликатов (хотя, если в плане трафика, то gzip с ними отлично справляется), можно собирать в отдельные поля в начальный result.



    Внешний слой API


    Внешний слой доступен непосредственно конечным клиентам. Он может представлять из себя веб-сайт или просто API для сторонних разработчиков.

    На внешнем слое мы НЕ предоставляем такую гибкость, как на внутреннем, а только даем доступ к базовым возможностям: основной параметр запроса, отступ, количество и т.п. Причем всё это с ограничениями.

    Отчасти он является прокси до внутреннего API с рядом важных дополнений.

    Сразу пример:
    app.get('/api/track/:id', ..., function(req, res) {
    	return app.model.Track.findOne({id: req.params.id});
    })
    


    Вместо «...» делаем необходимые проверки прав, модифицируем запрос, определяем формат. Данные возвращаются в том же формате и тем же путем, как были запрошены.
    Т.е. для http и json данные так и вернутся. Для socket и xml ответ будет через сокет и в xml.

    Таким образом мы можем полностью контролировать, что доступно извне, как, на каких условиях и так далее.


    Оптимизация тяжелых запросов


    До этого мы описывали работу с базой максимально абстрактно, и, само собой, подобные запросы будут выполняться значительно медленнее оптимизированных. С первым шагом мы обнаруживаем (с помощью профайлера, либо другим удобным вам способом), что какой-то из запросов работает медленно.

    Допустим, мы обратили внимание, что медленно работает запрос, в котором выбирается трек вместе с информацией об альбоме и музыканте. Для оптимизации нам понадобится создать новый внутренний метод:
    Model.extend('Track', {
    	'GET /track/{id}/withAdditionalData': function() {
    		var track = ...;
    		// Тут выбираем данные максимально оптимальным способом
    		// также используем по возможности кэш
    		return track;
    	}
    })
    

    и меняем вызов на внешнем слое ко внутреннему на представленный. Всё. Для конечного клиента ничего не поменялось, и кэш, и пути, и получаемые данные — те же, но вот работать всё стало быстрее.


    Пользователи


    Основная задача при работе с пользователями — проверять их права.

    Как только пользователь авторизуется (способ не важен: куки, ключ, другой вариант), мы делаем один запрос к внутреннему слою, удостоверяя личность и получая разрешения. Далее проверки мы будем делать на внешнем слое.


    Масштабирование


    Большие преимущества мы получаем именно на этапе масштабирования.

    И внешний и внутренний слой API мы можем запускать в любом количестве экземпляров, разруливая нагрузку с помощью балансеров. За счет подобного разделения мы можем запустить множество приложений с внешним слоем максимально близко к конечному клиенту, получив собственную CDN сеть с кэшированием данных.

    Базы данных расширяются классическими способами, зависящими от задачи.


    Кэширование


    Для внутреннего слоя мы кэшируем результаты запросов к базам данных, а на внешнем — результаты, полученные от внутреннего слоя. У конечного клиента тоже может быть кэширование.

    В одном из предыдущих примеров была строка «cache: 1800» — она может предоставить кэш как на внешнем слое, запоминая результат на сервере на полчаса, так и на клиенте, сложив результат, например в localStorage (ну или другое хранилище клиента).


    Версионирование


    С развитием вашего проекта будут появляться новые методы, а какие-либо старые — уходить. Для указания версий я рекомендую, несомненно, Семантическое Версионирование. Нас особо интересует изменение мажорной версии API, без обратной совместимости. Пути доступа к API можно разделить просто: /api/{version}

    Организовать файлы и поддержку разных версий можно несколькими путями, например:
    1. Сделать папки v1, v2 и поместить в них весь относящийся к ним код. При модификации одной из версий API другая не затрагивается.
    2. Различные репозитории, функционируют как различные приложения.


    Итог





    1. Мы имеем полный контроль над движением данных на всех этапах.
    2. Разработчики довольны, им не надо ждать от команды API реализации суперхитрого метода для получения данных в определённом формате.
    3. Разработчики довольны, они могут оптимизировать только то, что тормозит.
    4. Клиенты довольны — API стабильнее и не меняет пути из-за того, что какой-то запрос был тормозной.
    5. Клиенты довольны — скорость доступа увеличивается за счет расположения сервера максимально близко.


    Буду рад добавить в статью дополнительные разделы по вашему запросу.
    Также, если хотите уточнить где-то код — напишу и приложу, спрашивайте.
    Возможно, это начало большого цикла статей на различные темы (или начало уже было положено). Материала накопилось очень много, но он не систематизирован.

    Оффтопик вопрос про создание курсов для желающих разрабатывать веб проекты
    Я хочу создать полноценный курс по разработке веб проектов. Прямо с нуля и до full-stack.

    По планам он будет включать: видеолекции + текстовые уроки, домашние задания, самостоятельные проекты, работу с ментором, различные интенсивы, кучу кода (в формате запуска/доработки онлайн) и так далее. В качестве особенности хочу сделать «сетевой» формат, а не последовательный. Т.е. после прохождения определённых тем открываются другие, и ученик может сам выбирать, что его интересует в данный момент. По предварительным оценкам длительность обучения будет в районе полугода полноценных занятий по паре часов в день.

    Понятно, что подобный проект реализуется не так быстро. Потому подойти к его разработке я хочу именно с привлечения партнёра, на чьей базе его можно будет реализовывать / продавать. Т.к. если сопутствующие вопросы я возьму на себя, то срок реализации станет совсем запредельным. Ну и плюс у разных порталов различный инструментарий, который я хочу учесть.

    Я уже писал ряду проектов типа coursera с описанием своей затеи, но не получил никаких ответов. Причем, что обидно, вообще никаких, даже отказов.

    Рынок изучал и уверен, что то, что реализую, более чем конкурентоспособно.

    Буду рад любым предложениям о партнёрстве или советам, к кому следует обратиться.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 24

      +5
      А таки "Про Катю" очень злая шутка, я сразу и купился =(
        0
        Я думаю, минусят именно из-за этого :D
          +1
          Удалил. Вероятно mannaro прав.
          Честно говоря даже не предполагал что из-за шутки будут сливать хороший пост и карму.
          Ладно бы откомментировал кто — ты не прав, на самом деле делать надо вот так и вот так.
          После вот такой вот фигни никакого желания писать сюда нету, на самом деле.
          +3
          >Возраст: 25 лет
          >Опыт работы: 14 лет
          Пожалуй, тоже напишу, что пишу код с 10 лет :)

          А за статью плюс.
            +2
            Может мне тоже к годам опыта приплюсовать опыт программирование на G-Basic в

            СЮБОР
            image

            Тогда тоже можно сказать, что программирую лет с 12-13 :)
              +2
              Эх… Память детства
              0
              Ничего странного в этом нет. Сам пишу код с 12 лет, в 13 заработал первые деньги на этом и продолжаю в свои почти 27 уже.
              +2
              Какое отношение к разработке API имеет статическая страница для людей, пусть и приносящая 10 штук?

              Данный подход не имеет смысла для вас, если у вас маленький проект с небольшим количеством компонентов и разработчиков.

              О да, для больших приложений. Правильная работа с информацией и все такое. Легкое масштабирование. Расскажите-ка лучше, как избежать потери апдейта (т.е. информации) при обновлении одного ресурса двумя клиентами одновременно.

              Ну а то, что Вы рассказали — это банальное разделение приложения на слои, причем весьма, весьма посредственное (но это все же лучше, чем пришедшие от пользователя данные после валидации пихать сразу в Монгу).

              Извините за сарказм. Считаю, что имею право, так как пишу код с 9 лет :)
                +1
                Ура, первый комментарий по теме поста.

                Какое отношение к разработке API имеет статическая страница для людей, пусть и приносящая 10 штук?

                Это иллюстрация преимущества контента. Непосредственно к разработке API пример не относится.

                Расскажите-ка лучше, как избежать потери апдейта (т.е. информации) при обновлении одного ресурса двумя клиентами одновременно.

                Вопрос не достаточно полный что бы корректно ответить. Так же, зависит от информации, которую модифицируем. Приведу несколько примеров. Коль назвали монгу, применимо к ней.

                Общее золото в игре. Вместо выборки и установки нового значения мы можем использовать $inc — в таком случае обе операции, не зависимо от порядка, пройдут успешно. Отвечая на вопрос, что же делать если золото ушло в минус после подобной операции — откат софтварной транзакции и вывод информации о недостатке золота.

                В случае если это некая статья, на подобии википедии, то тут мы можем применить несколько вариантов.

                1. Храним историю изменений. Во время отправки текста помимо идентификатора записи указывается номер ревизии, и, в случае если он был изменён, возвращаем неудачу, сохраняя информацию во временное хранилище и показывая актуальные изменения. Вместо прямой выборки данных используем выборку обновлением, с указанием ревизии. Таким образом если документ не выбрался -> были изменения, если выбрался, то он сразу же был помечен новой ревизией.
                2. Банально храним дату изменения и при отправке изменений указываем от какого времени были эти изменения, в случае несоответствия показываем пользователю изменения и даем возможность решить что делать.

                Ну а то, что Вы рассказали — это банальное разделение приложения на слои, причем весьма, весьма посредственное (но это все же лучше, чем пришедшие от пользователя данные после валидации пихать сразу в Монгу).

                По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.
                Так вот это не просто и не легко, и умеет это не такая большая доля разработчиков на самом деле.
                В случае если у вас всё окружение умеет подобное и применяет — это мега круто. Значит вам удалось попасть в общество экспертов.

                причем весьма, весьма посредственное

                В чем посредственность — хотелось бы услышать конкретно. Что не так? Как лучше? Я рад учиться, если ошибся где то.
                  0
                  По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.

                  Вот именно это ощущение лично мне и дала Ваша статья. Кэширование? Нет ничего проще! Масштабирование? Легко! Версионирование? Проще простого! В то время как все это — сложные и в общем случае не имеющие универсального и простого решения проблемы. Я, конечно, не говорю об онлайн-Todo листах с тремя сущностями и четырьмя оперциями над ними.

                  Выше Вы описали, как можно разрулить потерянное обновление. Это ок, но противоречит данному в начале статьи обещанию показать, как масштабирование и пр. будет сделано без вмешательства в само приложение.
                    0
                    В данном случае изменение в любом случае затрагивает клиентскую часть, т.к. клиенту необходимо сообщать о данной ошибке.
                    Разруливание подобной ситуации к масштабированию имеет косвенное значение. Даже, скорее, это бизнес-задача, а никак не про масштабирование. В пример могу привести wikia — у моей игры есть там неофициальная вики, и люди жаловались о потере одновременных правок. Это реальная проблема была. Даже в таком крупном проекте решена плохо.

                    Как я уже говорил — в случае оптимизации и разноса по большому количеству серверов пути API будут одни и те же, хотя даже сервера могут находится в разных странах. И вот возврат этой ошибки — как раз сделает API.

                    Кэширование? Нет ничего проще! Масштабирование? Легко! Версионирование? Проще простого!

                    Как вы сказали дальше — универсальных решений нет. Именно по этому это уже не легко. Нет универсального решения -> надо подключать мозг.
                    Я могу написать сотни статей с конкретными юзкейсами. Но мне это не интересно :-) Да и смысла осоьбо не имеет, т.к. каждый новый случай, ваш случай, уже всё равно не в один из них не уложится. Как видишь даже с твоим вопросом я сразу предложил несколько вариаций, в зависимости от контекста. А таких ситуаций бесконечное множество.
                0
                API отличается от UI тем, что оно для программ, а не для юзеров.

                Вокруг любого более-менее популярного проекта крутится множество пользователей, среди которые встречаются айтишники разных уровней, и всегда найдутся те, кто начинает рисовать свои таблички, статистику и другое. Чем крупнее проект, те больше людей, тем больше шансов, что встретиться приличный или очень мотивированный программист, который напишет свой сайт, выдающий полезную (с точки зрения пользователей) информацию. Такой сайт может выглядеть как угодно и брать информацию любыми доступными способами.

                Если вы — владелец проекта, у вас несколько задач.
                Задача первая. Если делаете информативный сайт — это лишняя площадка для популяризирования, контроля информации и заработка на той же рекламе, плюс удобный способ продвигания нужнйо вам информации.

                Если вы делаете API, то это API, он должен возвращать в идеале не html, а xml/json, и выглядеть может как страничка-визитка с инструкцией по пользованию. Можно получить с него пользу, предоставляя бесплатный и платный доступ с разным функционалом (хотя бы с ограничением нагрузки для бесплатных пользователей). Если у вас крупный проект, вы можете оставить контакты SEO, чтобы с ним могли связаться админы тех порталов, которые смогли подняться на популярности до серьезного уровня, и сотрудничать с ними на индивидуальных условиях.

                Я за свою жизнь (да, кодю с 4 класса), успел поадминить 4 игровых проекта, с онлайном от 150 до 100.000, и ответственно заявляю — создатель игрового проекта, не сможет изначально продумать какая информация понадобится пользователям, и как они смогут заюзать фичи и баги игровой механики.
                Поэтому сотрудничество с независимыми создателями различных калькуляторов, сайтов статистики, и так далее — крайне полезно и для того, чтобы фиксить баги в балансе и механики, и выдавать отдельную информацию (зато контролируемо), и даже взаимно зарабатывать на таком сотрудничестве.

                Даже борьба с ботами может вестись через такое сотрудничество, когда можно договориться с создателем бота об определенном API, через который будут разрешены конкретные операции — это позволяет «правильным» ботам подавить «неправильные» боты на конкурентной основе.
                  0
                  Принципиальной разницы кто является клиентом API — пользователь или сторонняя программа, нет, т.к. стороннюю программу так же используют люди.

                  Дальше часть не очень понятна. В тексте статьи и так сказано что возвращать необходимо требуемыми способами.

                  В качестве интересного примера с внешней API можно взглянуть на Eve online, для которых делают вплоть до игровых онлайн казино.
                  В них играют пользователи, но, что бы играть, нужна платная подписка. В итоге сторонние разработчики за бесплатно продвигают твой товар (игру).

                  Если продолжаем про игры. Можно глянуть, например, Neverwinter. Из браузера ты можешь управлять отправкой помощников на задания. В WOW ты можешь мониторить аукцион. Таких примеров очень много.
                  Конечно, сразу определить какие действия разрешить — сложно, но вот выдавать ряд информации сразу возможно (например ситуацию на рынке).
                  Как я уже сказал, это не просто полезно, а приносит деньги владельцем проектов.
                    0
                    «Принципиальной разницы кто является клиентом API — пользователь или сторонняя
                    программа»

                    API — это Advanced Programmer Interface, а не Advanced User Interface или interactive user database access.

                    Если владелец продукта сам предоставляет онлайн-базу, то это не API, а онлайн база, онлайн статистика. Суть именно в этом — кто подключается — юзер или софт.
                      0
                      Ок, поясню.
                      Если нашим продуктом является, например, сайт.
                      Пользователь октрыл сайт (SPA), браузер делает запрос к API и выводит данные. Как бы это настолько очевидно что не пользователь лично делает этот запрос, что мне казалось излишнем подобное комментировать.

                      Если нашим API воспользовался сторонний разработчик — он либо получил данные к себе, либо вывел их в приложение конечному пользователю. Так или иначе пользователь увидел в продаже нужный ему чайник и купил его. У вас или через партнёра — деньги вы имеете в любом случае.
                        0
                        API запрос и HTTP запрос отличаются тем, что в случае API запроса, программа получает данные, с которыми она работает.
                        В случае HTTP запроса, выдается html страничка, которая рассчитана на то, что ее будет глазами смотреть пользователь. И чтобы программно можно было обработать данные из html странички, ее нужно парсить.

                        В общем тут нет смысла спорить, если вы не понимаете сути термина API
                          0
                          Что-то вы перепутали мягкое с желтым.
                          API запрос может идти через HTTP.
                          HTTP это протокол передачи данных, а какие там уже данные — вопрос третий.
                            0
                            «какие там уже данные — вопрос третий»
                            Не верно, это собственно главный вопрос. Ну оговорился с HTTP, знаю я что это такое. Но зачем сразу хвататься за слово? Мы обсуждаем термин API.

                            API запрос может идти вообще по чем угодно. Смысл термина в том, что API запрос возвращает данные не в human-friendly виде.
                              0
                              HTML это тоже не human-friendly вид.
                              В human-friendly его превращает браузер.

                              HTML является частным случаем XML. С данными в XML вопросов же нет, да? JSON тоже самое, в принципе.

                              Разница в том, что HTML содержит дополнительную служебную информацию.
                              Повторюсь — нет никакой принципиальной разницы в каком формате у нас возвращаются данные.

                              Если убрать из HTML всю служебку мы получим чистый контент разбитый семантически на логические блоки, который мы ровно точно так же можем распарсить в то, что нам требуется.
                              По факту парсинг JSON, XML, HTML или чего-либо отличается только наличием библиотек или встроенных инструментов.
                                –1
                                С вами спорить как со стеной.
                                HTML изначально предназначен для парсинга браузером, а не чем-нибудь еще, и сразу в friendly вид.
                                Вам про суть, а вы слово-за-слово, как троль какой-нибудь. Не хотите пытаться понимать суть, бегаете за словами и запятыми — закончим спор.
                  0
                  >>>Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?

                  Вы так и не рассказали, каким образом страница, на которой один только текст (который, очевидно, доступен всем и бесплатно) и нет графики (что, видимо, означает отсутствие рекламы) вообще приносил какие-то деньги.

                  >>>Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.

                  И что? Сам по себе pagerank не может приносить деньги. Был какой-то элемент (реклама, руководства за деньги, уроки), который и позволял зарабатывать. Какой?
                    0
                    Мануал приводил на, собственно, покер рум. Покер рум получал профит -> выплачивал владельцу страницы.
                    Хотя эта суть не очень относится к теме поста.
                    –1
                    Может быть как-нибудь напишу статью «Как обрабатывать миллион одновременных геораспределённых соединений и не обосраться» с конкретными примерами, когда NDA закончится и настроение будет.
                      0
                      Ну не хотите, так не напишу. Это проще же.

                    Only users with full accounts can post comments. Log in, please.