Недостатки поддержки общих условий запроса в API REST?

Question

Хотелось бы узнать, какие компромиссы имеют REST API, которые поддерживают широкий диапазон ограничений запросов. Я думаю о том, что делает API like that of Parse.

Parse's take on REST позволяет практически полностью построить инструкцию DB на клиенте, и я полагаю, что на сервере у них есть движок, который преобразует ключ where: {} JSON в правильный запрос Mongo, который включает в себя все определенные условия. Например, вот что-то можно было сделать:

curl -X GET \ 
    -H "X-Parse-Application-Id: xxx" \ 
    -H "X-Parse-REST-API-Key: xxx" \ 
    -G \ 
    --data-urlencode 'where={"hometown":{"$select":{"query":{"className":"Team","where":{"winPct":{"$gt":0.5}}},"key":"city"}}}' \ 
    --data-urlencode 'limit=200' \ 
    --data-urlencode 'skip=400' \ 
    https://api.parse.com/1/classes/_User 

Как вы можете видеть из раздела данных, можно было бы произвести некоторые довольно сложные и интересные вопросы на стороне клиента, используя эту очень гибкую систему. Теперь предположим, что вы не Parse, вы используете SQL, а ваш (частный!) API-интерфейс не должен поддерживать каждый мыслимый тип запроса, который мог бы сделать клиент, но вы все равно можете иметь возможность определить несколько ограничений здесь и там, чтобы избежать отправки данных клиенту, которые он не будет использовать, просто потому, что он не может определить запрос с достаточной точностью.

Является ли подход к генерации заявлений DB просто излишним в вышеупомянутом случае? Если да, то, что более простой способ иметь разные ресурсы, разделяет несколько ограничений (например, ограничение, пропуск, упорядочение), но не все из них? Некоторые могут быть специфическими для этого ресурса. Какие-нибудь большие ресурсы, которые говорят о различных дизайнерских решениях здесь?

Answer 1

Если вы хотите архитектуру RESTful, вам необходимо использовать HATEOAS, что означает, что запросы должны быть созданы на основе представлений, отправленных в предыдущих ответах. Поэтому «Механизм генерации DB-заявлений» не нужен, так как все параметры, которые могут быть установлены, будут предоставлены в виде шаблона сервером (например, HTML-форма, но, вероятно, что-то более сложное в вашем случае, возможно, XForms в тип настраиваемого контента). Ограничения будут определяться разметкой ввода формы. Выберите язык разметки, достаточный для описания всех ваших ограничений для клиента.