Должен я RESTify мои вызовы RPC по HTTP?
Приложения Android имеют то, что называется Разрешения , и приложение сообщает телефону, что оно хочет делать. Целью этого является защита конфиденциальности пользователя Android.
В последнее время Google Play стал более строгим в том, какие приложения позволяют использовать некоторые из этих разрешений, поскольку они часто используются вредоносными приложениями. Одним из таких разрешений является READ_SMS. Если приложению предоставлено это разрешение, ему разрешено читать все SMS-сообщения пользователей.
Из вашего комментария звучит так, будто вы не хотите, чтобы ваше приложение читало SMS-сообщения пользователей. Таким образом, в этом случае проверка сработала - ваше приложение запрашивало разрешение, в котором оно не нуждалось. Вы должны удалить запрос на разрешение READ_SMS из вашего приложения.
Инструкции по редактированию разрешений в здесь, в собственном приложении «Реакция», здесь . Поэтому, возможно, вы добавили это разрешение в свой файл AndroidManifest.xml. Если вы сделали, то вы должны удалить его.
Если вы не добавили его самостоятельно, возможно, плохая сторонняя библиотека, которую вы добавили в свое приложение, добавила разрешение. Если это так, вы должны прекратить использовать эту библиотеку.
3 ответа
Во-первых, все дело в семантике, URI - это индикатор Uniform Resource . HTTP предоставляет методы для GET, POST, PUT и DELETE ресурса. Заголовки HTTP указывают, в каком формате я хочу получать или отправлять информацию. Все это легко доступно через протокол HTTP.
Таким образом, вы можете повторно использовать тот же URL, который вы используете для вывода HTML, чтобы получить XML, JSON таким образом, как предполагалось использовать HTTP.
XML-RPC и SOAP основаны на методах вызова, которые описываются файлом XSD или WSDL, тогда как REST основан на получении / изменении ресурсов. Разница небольшая, но очевидная. URL-адрес описывает исключительно ресурс, а не действие, как это часто бывает с SOAP и XML-RPC.
Преимущества REST заключаются в том, что вы можете использовать HTTP-команды для изменения ресурса в соответствии с вызовом метода, который может называться create / new / add и т. Д. Значимые коды состояния HTTP вместо различных типов ответов об ошибках и возможность чтобы указать разные форматы для одного и того же ресурса стандартным способом.
Вам также не нужно принимать ВСЕ команды на ресурсе RESTful, например, если вы хотите, чтобы ресурс только для чтения просто возвращал код состояния 405 Метод запрещен для любого глагола, кроме GET.
Следует ли вам повторить вызовы RPC для REST? Нет, я так не думаю. Преимущества не перевешивают время разработки. Стоит ли изучать REST при настройке нового веб-сервиса? Да, лично я так считаю, потребление ресурса REST будет более естественным и может расти намного быстрее.
РЕДАКТИРОВАТЬ
Я считаю, что REST побеждает XML-RPC / SOAP в том, что при разработке веб-сайтов вы уже агрегируете все необходимые данные для вывода в HTML, а также пишете проверочный код для тел POST. Почему вы должны переходить на другой протокол только из-за изменения транспортной разметки?
Таким образом, когда вы разрабатываете новый веб-сайт (языковой независимый), если вы действительно думаете об URI как о ресурсах, вы в основном используете свои URI как вызовы методов с HTTP-глаголом префикс вызова метода.
То есть GET на / products / 12 с HTTP-заголовком Accept: application / json; в основном (воображаемый) переводится в getProducts (12, MimeType.Json ) .
Затем этот «метод» должен сделать несколько вещей
- Проверить, поддерживаем ли мы JSON как тип MIME. (Проверить запрос)
- Проверить данные запроса
- Сводные данные для продукта 12.
- Отформатировать в JSON и вернуть.
Если по какой-то причине в ближайшие 4 года YAML будет стать следующим большим увлечением, и один из ваших потребителей хочет поговорить с вами таким образом, что этот тип MIME подключается намного проще, чем с обычными веб-службами.
Теперь продукт 12 - это ресурс, который, скорее всего, также захочет принять типы HTML MIME для отображения указанного продукта, но для URI типа / product / 12 / reviews / 14 / вам не нужно аналог HTML, вы просто хотите, чтобы ваши потребители могли отправлять сообщения по этому URL-адресу для обновления (PUT) / удаления (DELETE) своего собственного обзора.
Рассматривая URI строго как ресурсы, а не просто расположение веб-страницы , а эти ресурсы, в свою очередь, в сочетании с HTTP-запросом на вызовы методов на стороне сервера приводят к чистым (оптимизированным для SEO) URL-адресам и (что более важно?) к простоте разработки.
Я уверен, что на любом языке есть фреймворки, которые будут автоматически выполняет сопоставление URI с вызовами методов за вас. Я не могу рекомендовать один, поскольку обычно выкатываю свой собственный.
ASP.NET MVC также работает по тому же принципу, но, на мой взгляд, он не создает RESTful URI. ASP.NET MVC делает глагол частью URI по умолчанию, сказав, что хорошо отметить, что ни в коем случае ASP.NET MVC не навязывает вам это (или что-то еще в этом отношении).
Если вы собираетесь выбрать структуру, по крайней мере, они должны:
- Привязать URI к методам на сервере
- Объект поддержки для сериализации JSON / XML и т. д. Это' Боль, если вам придется писать это самостоятельно, хотя, в зависимости от языка, это не обязательно слишком сложно.
- Предоставьте какие-то типобезопасные помощники запросов, которые помогут вам определить, что было запрошено, без ручного анализа заголовков HTTP.
Строки запроса не должны использоваться для доступа к ресурсу в иерархической, не связанной с запросом манере. При кэшировании строки запроса обычно игнорируются, что опасно и медленно.