API-интерфейс типа ebay для веб-портала
https://stackoverflow.com/questions/1231532
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Мы разработали веб-портал B2B для графических работ, похожий на Camera Ready Art (www.camerareadyart.com).Он предназначен для людей, желающих конвертировать растровые изображения в векторную графику, разрабатывать логотипы и выполнять общую обработку изображений, например раскрашивать черно-белые изображения в цвет и т. д.
Мы хотим добавить возможность, чтобы люди (наши клиенты) могли использовать набор API, который мы предоставляем, для публикации своей работы напрямую со своего сайта, без необходимости буквально посещать наш сайт, чтобы опубликовать свою работу.
До сих пор я никогда не делал ничего подобного, поэтому у меня нет идей относительно того, как я могу реализовать что-то подобное.Я также хочу знать, как мы можем реализовать безопасность, чтобы только те, кто авторизован, могли публиковать свои работы?
Может ли кто-нибудь дать мне идеи относительно того, как мы можем сделать что-то подобное?
Решение
Этот вопрос охватывает очень большую область, и я сомневаюсь, что какой-либо один ответ может охватить все детали.Что я могу сделать, так это предложить некоторые отправные точки, основанные на допущенных мною ошибках.
Создайте свой собственный API
Не добавляйте функции API в существующую систему.Это позволит:
- приведет к дополнительной тестовой нагрузке (вам придется тестировать приложение и API независимо друг от друга)
- приводит к увеличению общих затрат на техническое обслуживание
- приведет к более низкому качеству API, чем то, что вы хотите предложить.
Ваша общая цель должна заключаться в том, чтобы сначала создать API, а затем создать приложение на основе собственного API.Это дает следующие преимущества:
- тестирование API по сути выполняется во время тестирования вашего приложения.
- вы не «забудете» добавить необходимые методы API
Ваше приложение и логика вашего приложения (API) будут логически разделены — между ними будет четкое разделение с точки зрения того, что делает каждая сторона уравнения и за что она отвечает.Это поможет направить развитие.Это также позволит вам очень легко разместить приложение и API на разных машинах по мере необходимости.
Использование собственного API — очень важный момент.Изначально дизайн вашего API будет неоптимальным, и только используя его самостоятельно, вы сможете заставить его предлагать людям действительно необходимые функции эффективным способом.
В итоге у вас получится система, которая примерно выглядит так:
------------- -------------
| | | |
| Your APP | <= HTTP communication => | Your API |
| | | |
------------- -------------
Это подчеркивает некоторые дополнительные преимущества:вы можете заменить «Ваше приложение» любым другим приложением, что позволит вашим клиентам создавать приложения, которые будут решать проблемы наиболее удобным для них способом.Вы также можете создавать новые версии своего приложения поверх существующего API — переход на новую версию вашего общедоступного веб-сайта может быть намного проще.
Разработка URL-адресов:сопоставление с классами и методами
Выбор разумных URL-адресов — такая же проблема, как и выбор разумных имен классов и методов.Получение URL-адресов из классов и их методов — хороший подход.Если нет разумной корреляции между URL-адресами и классами/методами, вам будет сложнее поддерживать их в долгосрочной перспективе.
Лично я предпочитаю связывать URL-адреса с классами и методами следующими способами:
- сопоставлять классы с каталогами верхнего уровня
- сопоставить методы с подкаталогами каталогов верхнего уровня
Пример:
URL-адрес вашего API: https://api.camerareadyart.com.
У вас есть image объект с toColour() и toBlackAndWhite() методы.
Это может соответствовать:
https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/
Аналогично для преобразования растрового изображения в векторное:
https://api.camerareadyart.com/bitmap/toVector/
Разработка ответов
Что происходит, когда кто-то получает данные или отправляет данные POST на один из ваших URL-адресов?Как обрабатываются ошибки, как обрабатываются исключения?В какой форме принимаются ответы?
Я не могу сказать тебе, что здесь делать.Лично я предпочитаю как можно ближе сопоставлять вещи с HTTP, а затем выходить за рамки этого только при необходимости.
Например, если входящий запрос принят и обработан, но сталкивается с внутренней ошибкой, я бы выдал ответ со статусом 500.Аналогично, если данный метод API требует аутентификации, которая не была предоставлена, я могу выдать ошибку 403.Использование существующих функций HTTP избавляет вас от необходимости заново изобретать некоторые вещи.
Используйте существующие аспекты HTTP
Помимо разумного использования кодов состояния HTTP, обязательно найдите метод, позволяющий что-то сделать только с помощью HTTP, прежде чем развертывать собственное решение.
Хотите, чтобы пользователь указал, должен ли формат ответа быть XML или JSON?Используйте заголовок HTTP Accept.
Хотите перенаправить клиента на другой URL-адрес, чтобы получить результат запроса?Используйте заголовок HTTP Location.
В HTTP имеется множество функций, которые уже позволяют выполнять многие задачи, которые вы, возможно, захотите сделать.Используй их!
Безопасность
Здесь необходимо решить две общие проблемы:аутентификация пользователя и определение того, какие действия может выполнять данный пользователь.
Безопасность:аутентификация
Пользователю необходимо будет указать в своем запросе, кто он.
Первое решение, которое приходит на ум, — позволить пользователю указать имя пользователя и пароль, возможно, такие же, как имя пользователя и пароль, которые он использует для доступа к вашему приложению.На первый взгляд это хорошая идея, но она не идеальна.
В конечном итоге пользователи впишут свое имя пользователя и пароль в свои собственные приложения.Неизбежно один пользователь забудет свой пароль и изменит его, чтобы иметь возможность беспрепятственно получить доступ к вашему приложению, сломав при этом свое собственное приложение.
Лучшим выбором было бы, чтобы пользователь предоставил токен аутентификации, который, по сути, представляет собой одно значение, уникальное для пользователя, во многом похожее на имя пользователя и пароль, объединенные в одно.
Это позволяет логически отделить имя пользователя и пароль от доступа к API.Пользователь может менять свое имя пользователя и/или пароль для вашего приложения так часто, как пожелает, не нарушая при этом свой доступ к API.
Пользователь также может иметь несколько токенов API, каждый из которых имеет разные уровни доступа, что позволяет пользователю безопасно передавать токен API сторонней службе.
Безопасность:контроль доступа
Что касается внешнего мира, ваш API представляет собой набор URL-адресов.Каждый URL-адрес по определению уникален и выполняет уникальную задачу.Основание ваших механизмов контроля доступа на этих концепциях является хорошей отправной точкой.
Я предпочитаю вести список URL-адресов для каждого токена, к которым разрешен доступ.Когда для доступа к URL-адресу используется определенный токен, определить, к какому URL-адресу осуществляется доступ, и находится ли он в списке разрешенных URL-адресов токена, не составляет труда.
Если вы разумно выберете набор URL-адресов, где каждый URL-адрес выполняет одно уникальное действие, этот процесс предоставит вам примерно лучший уровень контроля доступа, который вы сможете получить.
Чтобы обеспечить более высокий уровень контроля, вы также можете указать для каждого URL-адреса, к которому токен имеет доступ, какие аргументы запроса им разрешено использовать.
Другие советы
Очевидно, вам нужно, чтобы ваши серверные веб-сервисы были разработаны и работали. Однако все дополнительные функции (безопасность, регулирование, управление ключами OAuth, портал подписчиков, интерактивная консоль для тестирования API и т. Д.) Представляют собой довольно стандартный набор функций, которые вы, вероятно, не должны разрабатывать самостоятельно.
На рынке имеются коммерческие решения для управления API. Я работаю для WSO2, который имеет 100% -й открытый API-интерфейс WSO2 Manager с лицензией Apache, который вы можете бесплатно скачать здесь или используйте как размещенную в облаке версию в облаке WSO2 API .
