Определение API - это RPC или REST

Question

Я недавно разработал REST API, используя колбу для примера проекта. Внешний интерфейс был основан на React.JS. Но я получил отзыв от коллеги, что API - это не REST API, а его RPC.

API в основном принимает 3 параметра, 2 числа и одну операцию ('add', 'sub', 'mul', 'div'). в конечной точке http://127.0.0.1:5000/calculator Входной JSON будет выглядеть так:

{"value1":"7.1","value2":"8","operator":"mul"}

from flask import Flask, jsonify, request, abort
from flask_cors import CORS

APP = Flask(__name__, static_url_path='')
CORS(APP)  # For cross origin resource sharing
APP.config['CORS_HEADERS'] = 'Content-Type'

@APP.route('/calculator', methods=['POST'])
def calculator_operation():

    if not request.json:
        abort(400)
    try:
        val1 = float(request.json['value1'])
        val2 = float(request.json['value2'])
        operator = request.json['operator']
        if operator == 'add':
            result = val1 + vla2
        elif operator == 'mul':
            result = val1 * val2
        elif operator == 'sub':
            result = val1 - val2
        elif operator == 'div' and val2 == 0:
            result = 'Cant divide by 0'
        elif operator == 'div':
            result = round((val1 / val2), 2)

        return (jsonify({'result': result}), 200)
    except KeyError:

        abort(400)

if __name__ == '__main__':
    APP.run(debug=True)

Код работает нормально. Я хотел бы знать, является ли это REST или RPC на основе конечных точек и выполняемой операции.

РЕДАКТИРОВАТЬ:

Ajax Call

$.ajax({
            type: "POST",
            url: "http://127.0.0.1:5000/calculator",
            data: JSON.stringify({
                value1: arg1,
                value2: arg2,
                operator: this.state.operation
            }),
            contentType: "application/json",
            dataType: "json",
            success:( data ) => {
                this.setState({ result: data.result, argumentStr: data.result });
            },
            error: (err) => {
                console.log(err);
            }
        });

Answer 1

REST означает REpresentational State Transfer.Ваша операция не имеет состояния, поэтому нет состояния для передачи.Однако ваша операция принимает аргументы и возвращает результат в виде процедуры или функции, и она является удаленной, поэтому удаленный вызов процедуры будет хорошим описанием того, что происходит.В конце концов, вы предоставляете клиентам независимый от языка способ вызова вашей calculator_operation процедуры.

Что явно не хватает в вашей модели - это данные на стороне сервера.В целом, REST API предоставляет способ взаимодействия с объектами на стороне сервера: для запроса, создания, замены, обновления или удаления.На вашем сервере нет никаких данных: это просто оракул, который отвечает на вопросы.У вас есть аспект «запрос» и ничего больше.

Answer 2

Я хотел бы знать, является ли это REST или RPC на основе конечных точек и выполняемой операции.

Как клиент обнаруживает, что такое конечная точка и каковаinput json выглядит как?

В Интернете был бы стандартный тип носителя, который описывает формы;представление формы будет включать ключи и значения, целевой URI и метод HTTP для использования.Правила обработки описывают, как получить подробную информацию о форме и значениях, предоставленных потребителем, и из них создать HTTP-запрос.

Это REST: делать то, что мы делаем в Интернете.

Другой подход REST будет состоять в том, чтобы определить отношение ссылки , возможно "http://example.org/calculator", и тип носителя application/prs.calculator+json, а затем задокументировать это в вашем контексте" http://example.org/calculator" отношение ссылки указывает, что целевой URI отвечает на сообщения POST с полезной нагрузкой application/prs.calculator+json.По сути, это то, что Синдикация Atom и Паб Atom .

Это также ОТДЫХ.

Филдинг сделал интересный комментарий о API, который онЯ разработал

Я должен также отметить, что вышеупомянутое еще не полностью RESTful, по крайней мере, как я использую этот термин.Все, что я сделал, это описал сервисные интерфейсы, которые не более чем любой RPC.Чтобы сделать его RESTful, мне нужно было бы добавить гипертекст, чтобы представить и определить сервис, описать, как выполнить отображение с использованием форм и / или шаблонов ссылок, и предоставить код для объединения визуализаций полезными способами.

Тем не менее, если вы выполняете GET-with-a-payload, семантически безопасный запрос с телом, то вы, вероятно, попали в ловушку RPC-мышления.Обратите внимание, что в Интернете параметризованное чтение выполняется путем сообщения клиенту, как изменить target-uri (например, путем добавления строки запроса с данными, закодированными в соответствии со стандартизированными правилами обработки).