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

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

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

ОТВЕТЫ

Ответ 1

Сервис калькулятора был бы простым в модели 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 очень сложный запрос к ресурсу калькулятора (передавая запрос как тело запроса), и сервер может вернуть 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 может дать вам достойную книгу как этот, а затем задумайтесь над тем, чтобы получить полную историю.

Ответ 2

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

Действие, выполняемое методом POST, может не привести к ресурсу которые могут быть идентифицированы с помощью URI. В этом случае либо 200 (OK), либо 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-адресов. Вы также можете поддерживать различные представления для запросов и ответов.

Ответ 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 может быть легко читаемой формулой.

Eg./API/v1/калькуляторы/mycalc/+ 9/-4/* 3/+ 10 вернет 25.

Ответ 4

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