В Google еще в самом начале осознали, что API-доступ сыграет существенную роль в успехе любого веб-сайта. Определенно, первые API системы представляли собой нечто большее, чем методы GET или POST, которые могут легко интегрироваться в другой HTML, что на первый взгляд не так уж ново. В конце концов, понятие гипертекста основано на допущении о связывании информации с помощью HTTP.
Однако, Google и проекты вроде Facebook продолжили свой путь от гипертекста к гиперданным -- интеграции посредством REST-интерфейса, возвращающего данные, а не HTML-текст и позволяющего использовать и отображать их в удобном для интегратора формате, а также способного интегрироваться с другими сервисами (например, картами) и источниками данных.
Это важно, ведь HTML, хоть и отлично подходит для интернета, не всегда находится в нужном для платформы формате. Я бы хотел добавить короткое объявление типа "пропал ребенок" на любой странице -- или в верхнем/нижнем колонтитуле или боковой панели -- которое затем объединяется с другой информацией, позволяя пользователям узнать больше и послужить общественности.
Еще я бы хотел локализировать данные, чтобы одновременно с конечными пользователями по сайту "перемещалась" и информация о пропавших детях.
Виджеты и гаджеты -- термины, которые уверенно входят в сферу мобильных технологий -- раньше представляли собой один из нескольких возможных форматов, похожих на параметры, доступные пользователям планшетов сегодня. Главное -- это размер и стиль, но не обязательно представление и дизайн. Как правило, данные отображаются в соответствии с задумкой разработчика.
Параметры интеграции предполагают варианты отображения и форматы, которые не отвечают требованиям сайта или игнорируются, поскольку не предоставляют удобный для пользователя формат вывода.
Например, сейчас оповещения системы AMBER можно получать в виде текстового сообщения. Но если вы плохо ориентируетесь на местности, такое сообщение бесполезно. Если данные доставили в простом стандартном формате, их можно быстро вывести в картографическое приложение, которое точно укажет, в каком районе пропал ребенок по отношению к вашему местонахождению.
Из-за ограниченности данных пользователю доступны лишь несколько почтовых индексов, а оповещения не дают точно определить, где находится "улица Мира".
Отсутствие API, акцент на гиперданных вместо гипиртекста и на подаче данных вместо предварительно форматированной информации, ставят под угрозу ваши возможности. Приложение, не интегрирующееся с остальными сервисами со сфокусированным на данных API, считается слишком устаревшим, чтобы быть эффективным. Особенно это касается приложений, нацеленных на обмен данными. Подобные приложения обязаны предоставить к ним доступ, иначе их ждет провал.
В случае с веб-приложениями, инфраструктурой и соцсетями, это может означать снижение дохода. В остальных -- ребенка просто никогда не найдут.
Гиперданные и API способны помочь в таком важном деле, нужно просто дать им шанс.
источник
Однако, Google и проекты вроде Facebook продолжили свой путь от гипертекста к гиперданным -- интеграции посредством REST-интерфейса, возвращающего данные, а не HTML-текст и позволяющего использовать и отображать их в удобном для интегратора формате, а также способного интегрироваться с другими сервисами (например, картами) и источниками данных.
Это важно, ведь HTML, хоть и отлично подходит для интернета, не всегда находится в нужном для платформы формате. Я бы хотел добавить короткое объявление типа "пропал ребенок" на любой странице -- или в верхнем/нижнем колонтитуле или боковой панели -- которое затем объединяется с другой информацией, позволяя пользователям узнать больше и послужить общественности.
Еще я бы хотел локализировать данные, чтобы одновременно с конечными пользователями по сайту "перемещалась" и информация о пропавших детях.
Виджеты и гаджеты -- термины, которые уверенно входят в сферу мобильных технологий -- раньше представляли собой один из нескольких возможных форматов, похожих на параметры, доступные пользователям планшетов сегодня. Главное -- это размер и стиль, но не обязательно представление и дизайн. Как правило, данные отображаются в соответствии с задумкой разработчика.
Параметры интеграции предполагают варианты отображения и форматы, которые не отвечают требованиям сайта или игнорируются, поскольку не предоставляют удобный для пользователя формат вывода.
Например, сейчас оповещения системы AMBER можно получать в виде текстового сообщения. Но если вы плохо ориентируетесь на местности, такое сообщение бесполезно. Если данные доставили в простом стандартном формате, их можно быстро вывести в картографическое приложение, которое точно укажет, в каком районе пропал ребенок по отношению к вашему местонахождению.
Из-за ограниченности данных пользователю доступны лишь несколько почтовых индексов, а оповещения не дают точно определить, где находится "улица Мира".
Отсутствие API, акцент на гиперданных вместо гипиртекста и на подаче данных вместо предварительно форматированной информации, ставят под угрозу ваши возможности. Приложение, не интегрирующееся с остальными сервисами со сфокусированным на данных API, считается слишком устаревшим, чтобы быть эффективным. Особенно это касается приложений, нацеленных на обмен данными. Подобные приложения обязаны предоставить к ним доступ, иначе их ждет провал.
В случае с веб-приложениями, инфраструктурой и соцсетями, это может означать снижение дохода. В остальных -- ребенка просто никогда не найдут.
Гиперданные и API способны помочь в таком важном деле, нужно просто дать им шанс.
источник
Комментариев нет:
Отправить комментарий