Как я могу создать RESTful калькулятор?

Question

Учитывая, что все веб-сервисы RESTful основаны на священной идее, что «все представлено в виде ресурсов и может быть доступно по адресу (URI)», это может иметь смысл для приложений CRUD (все примеры касаются перечисления / создания /обновление / удаление объектов).Однако как насчет другой бизнес-логики, такой как, например, создание простого сервиса RESTful калькулятора, который не имеет ничего общего с операциями CRUD?Что может быть хорошим дизайном для такой службы REST?

Во-вторых, каково реальное преимущество использования REST по сравнению с SOAP, если логика SOAP уже имеет полный смысл?

Answer 1

HTTP POST не обязательно должен создавать постоянный ресурс.В RFC 2616, раздел 9.5 , мы находим:

Действие, выполняемое методом POST, может не привести к ресурсу, который может быть идентифицирован по URI.В этом случае либо 200 (ОК), либо 204 (Нет содержимого) - это соответствующий статус ответа, в зависимости от того, содержит ли ответ объект, описывающий результат.

Это означает, что мы можем думатьо "создании расчета" без необходимости сохранять результат этого расчета на своем собственном URL.Ваш API-интерфейс может выглядеть следующим образом:

Request:
POST /calculations
Content-Type: text/plain

3 + 3 / 12 ^ ( 3 * PI)

Response:
200 OK
Content-Type: text/plain

3.005454

Преимущество этого заключается в том, что вы не передаете «контент» через URL-адрес, который будет прерываться при попытке отправить длинный расчет через клиента или прокси сограниченная длина для URL.Вы также можете сделать поддержку различных представлений для запросов и ответов.

Answer 2

Сервис калькулятора будет прост в моделировании в режиме RESTful.«R» в «CRUD» означает «чтение», и нет никаких причин, по которым «читать» также не может означать «вычислить».Таким образом, простой сервис калькулятора Reverse Polish можно получить через GET:

GET https://calc.com/rpnCalc?3&4&%2B
7

Приведенная выше схема URI просто добавляет три параметра в запрос GET:

3
4
+ (URL-encoded as %2B)

Это идемпотентный, безопасный и кешируемый запрос.Если бы это был безумно сложный математический запрос, для вычисления которого потребовалось много минут, я мог бы направить эти запросы в готовый HTTP-прокси и использовать его для мгновенного возврата любых предварительно вычисленных значений, если один и тот же URI будет запрашиваться повторно.

В зависимости от видов вычислений, которые вам нужно выполнить, вы также можете POST очень сложный запрос к ресурсу Calculator (передавая запрос в качестве тела запроса), и сервер может вернуть URI в «результат»ресурс, который вы можете затем ПОЛУЧИТЬ, чтобы получить результаты и даже разбить их на страницы.

Во-вторых, каково реальное преимущество использования REST по сравнению с SOAP, если логика SOAP уже имеет полный смысл?

Я могу получить доступ к вышеуказанному сервису калькулятора, используя инструмент командной строки, такой как curl , не создавая сложную часть SOAP.Я могу закодировать вызовы к нему за считанные секунды, не используя какую-либо стороннюю библиотеку XML или инструментарий SOAP.Я могу использовать обычные инструменты, такие как HTTP прокси, для кэширования результатов и повышения производительности.Мне не нужно беспокоиться о совместимости SOAP или проверять совместимость с WS-I.Если я правильно использую гиперссылки, я могу развивать и улучшать свой сервис, не затрагивая существующих клиентов и не заставляя их даже перекомпилировать.Нет версии WSDL и нет хрупкого контракта, который я должен поддерживать годами.Клиенты уже знают, что делают GET / PUT / POST / DELETE, и мне не нужно переопределять или заново документировать их семантику.Клиенты API, решающие, что предпочтут JSON вместо XML, могут получить его с помощью встроенной функции согласования содержимого HTTP.Я могу сделать абсолютно ноль этих вещей с помощью SOAP и веб-служб.

Эй, если SOAP соответствует вашим потребностям, примите это.Есть много преимуществ использования REST, но они могут не соответствовать вашей ситуации.По крайней мере, узнайте о том, что REST может дать вам с приличной книгой , как эта , а затем решитесь после получения полной истории.

Answer 3

Этому вопросу пару лет.Но все же кажется вопрос, который смущает меня и многих моих коллег.Мы не смогли найти решение, которое удовлетворит всех.

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

/**
 * This class defines a CalculatorResource.
 */

@Path("v{version}/calculators/{id}")
@Named
public class CalculatorResource {

    private final Long value;

    public CalculatorResource() {
        value = 0L;
    }

    public CalculatorResource(Long initialValue) {
        this.value = initialValue;
    }

    @GET
    public Long getValue() {
        return value;
    }

    @Path("+{value}")
    public CalculatorResource add(@PathParam("value") Long value) {
        return new CalculatorResource(this.value + value);
    }

    @Path("-{value}")
    public CalculatorResource subtract(@PathParam("value") Long value) {
        return new CalculatorResource(this.value - value);
    }

    @Path("*{value}")
    public CalculatorResource multiply(@PathParam("value") Long value) {
        return new CalculatorResource(this.value * value);
    }

}

---

При такой реализации URI может быть легко читаемой формулой.

Например./ api / v1 / калькуляторы / mycalc / + 9 / -4 / * 3 / + 10 вернет 25.

Answer 4

Это хороший пример напряжения между существительными и глаголами в REST. Предложение использовать «добавить» или «сумматор» в качестве ресурса чрезвычайно наивно. Это означает, что каждая операция должна быть выполнена как GET для «сумматора» или «вычитателя». Конечно, можно иметь ресурс «рассчитать», но тогда мы используем глагол. Мы можем изменить его на «калькулятор» или «ответ», которые являются существительными, но мы действительно ничего полезного не сделали.