Существует несколько способов это может быть сделано. В конце концов он должен быть чистым, независимо от того, какую метку вы хотите ему дать (REST non-REST). REST - это не протокол с RFC,поэтому не беспокойтесь слишком сильно о том, какую информацию вы передаете в виде URL-путей или URL-парамов. Базовый веб-сервис должен быть в состоянии предоставить вам данные независимо от того, как они передаются. Например, Java Jersey даст вам ваши params независимо от того, являются ли они param или URL path, это просто аннотация разница.

Возвращаясь к вашей конкретной проблеме, я думаю, что ресурс в этом вызове типа REST - это не столько данные, которые используются для выполнения числовых операций, сколько фактический ответ. В этом случае может быть достаточно записи, в которой идентификатор данных и операции являются полями.

POST http://my.api/operations/

{
    "dataId": "123",
    "operations": [
        {
            "type": "add",
            "value": 10
        },
        {
            "type": "multiply",
            "value": 5
        }
    ]
}

Ответ должен был бы указывать на место, где результат может быть получен, как вы указали. Результат, на который ссылается местоположение (и идентификатор) в ответ, по существу, является неизменным объектом. Таким образом, это фактически ресурс, созданный постом, а не данные, используемые для расчета этого результата. Это просто другой способ его просмотра.

EDIT: в ответ на ваш комментарий о нежелании хранить результаты операций, вы можете использовать обратный вызов для передачи результатов операции вызывающему абоненту. Вы можете легко добавить поле a во вход JSON для хоста или URL обратного вызова. Если URL обратного вызова присутствует, затем вы можете опубликовать на этом URL-адресе результаты операции.

{
    "dataId": "123",
    "operations": [
        {
            "type": "add",
            "value": 10
        },
        {
            "type": "multiply",
            "value": 5
        }
    ],
    "callBack": "<HOST or URL>"
}

пожалуйста, не рассматривайте это как ответ на мой собственный вопрос,а скорее как дополнение к обсуждению.

Я дал много думал в это. Основная проблема с предлагаемыми в настоящее время архитектурами-это масштабируемость, так как сервер создает копии данных каждый раз, когда он работает.

Единственный способ избежать этого-моделировать operations и data отдельно. Итак, подобно ответу Хосе, мы создаем ресурс:

POST http://my.api/operations/
{add:10, multiply:5}

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

201 Created
Location: http://my.api/operations/{uniqueid}

Следующим шагом является применение operations к данным:

GET http://my.api/data/123/operations/{uniqueid}

Этот подход к моделированию отдельных объектов имеет несколько преимуществ:

1. данные не реплицируются каждый раз, когда применяется другой набор операций.
Пользователи создают только ресурсы operations, и поскольку их размер мал, нам не нужно беспокоиться о масштабируемости.

2. Пользователи создают новый ресурс только тогда, когда им требуетсяНовый набор операций.Переход к примеру изображения: если я разрабатываю веб-сайт в оттенках серого и хочу, чтобы все изображения были преобразованы в оттенки серого, я могу сделать

   POST http://my.api/operations/
   {greyscale: "50%"}
   

   А затем примените эту операцию ко всем моим изображениям следующим образом:

   GET http://my.api/image/{image_id}/operations/{geyscale_id}
   

   Пока я не хочу изменять набор операций, я могу использовать только GET.

3. Общие операции могут быть созданы и сохранены на сервере, поэтому пользователи не делают этого. придется их создавать. Например:

   GET http://my.api/image/{image_id}/operations/flip
   

   , где operations/flip - уже доступный набор операций.

4. Легко, применяя один и тот же набор операций к разным данным, и наоборот.

   GET http://my.api/data/{id1},{id2}/operations/{some_operation}
   

   Позволяет сравнить два набора данных, которые обрабатываются аналогично. Альтернативно:

   GET http://my.api/data/{id1}/operations/{some_operation},{another_operation}
   

   Позволяет увидеть, как различные процедуры обработки влияют на результат.

Я бы не стал пытаться описать вашу математическую функцию с помощью URI или тела запроса. У нас есть более или менее стандартный язык для описания математики, поэтому вы можете использовать какой-то шаблон.

GET http://my.api/data/123?transform="5*(data+10)"
POST http://my.api/data/123 {"transform": "5*({data}+10)"}

Вам нужен код на стороне клиента, который может создавать такие шаблоны, и другой код на стороне сервера, который может проверять, анализировать и т. д... шаблоны, созданные клиентом.