Приложение RESTful, хотите отправить запрос SQL в качестве запроса на чтение

Question

Я работаю над веб-приложением RESTful. Теперь я хочу расширить запрос чтения (GET) для обработки SQL-подобных запросов, но я не смог закодировать их в URL-адресе из-за всех специальных символов («", "/", "<", ">", "{", "}", и т.д.). Я уже читал, что не рекомендуется использовать тело сообщения в запросе GET. Поэтому на данный момент единственным вариантом, который я вижу, является использование запроса POST. Но чем я еще раз скажу, что это нехорошее решение, потому что я бы использовал POST для операции чтения. В соответствии с принципами REST чтение должно выполняться с помощью запроса GET, и POST следует использовать только для управления данными.

Как вы думаете? Каков наилучший способ отправки SQL-подобных запросов в мое веб-приложение?

Большое спасибо

Answer 1

Использование CGI :: побег ("выберите * из NEVER_DO_SUCH_THINGS где SQL_INJECTION> 'небезопасным'")

Answer 2

Смотрите OData URI Conventions на один пример того, как набивать операции запроса в URI ,

Однако вы слишком ограничиваете использование POST. Идея методов HTTP заключается в том, что когда характеристики запроса соответствуют настройкам GET, PUT и DELETE, вы должны использовать их .. Вы НЕ ДОЛЖНЫ использовать, если характеристики не совпадают. Однако POST - это подстановочный метод, который может использоваться для любого запроса.

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

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

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