Flask: Как следует организовать функции маршрутизации в SOA? - PullRequest
Новая
       33

Flask: Как следует организовать функции маршрутизации в SOA?

0 голосов
/ 17 февраля 2020

Начало проекта Flask простое: 

# main.py

from flask import Flask, render_template,

app = Flask(__name__)

@app.route('/')
def hello():
    return render_template('index.html')

Выше указано только одна функция маршрута.

Но что происходит, когда у нас много маршрутов? Некоторые обработчики маршрутов предоставляют RESTful API для изменения определенного ресурса, в то время как другие обработчики маршрутов отображают представления (шаблоны). 

# main.py

# Returns an api endpoint
@app.route('/api/v1/students/', methods=['GET', 'POST'])
def students():
    if request.method == 'POST':
        return create_student(request.form['id'])
    if request.method == 'GET':
        return jsonify(fetch_students())

# Returns another endpoint (that is unrelated to the one above)
@app.route('/api/v1/courses/', methods=['GET', 'POST'])
def courses():
    if request.method == 'POST':
        return create_course(request.form['course-title'])
    if request.method == 'GET':
        return jsonify(fetch_courses())

# Renders a view (unrelated to the above endpoints)
@app.route('/campus-life/', methods=['GET'])
def campus_life():
    return render_template('campus-life.html')

Вверху: три несвязанных обработчика запросов находятся внутри main.py.

В подходе SOA к структурированию приложения, сервисов (модулей или пакетов) эти открытые API будут содержаться в их собственном файле или каталоге. Таким образом, эти обработчики маршрутов определены за пределами main.py. Как приложение регистрирует существование этих обработчиков маршрутов?

В более широком смысле, каков рекомендуемый способ организации и структурирования обработчиков маршрутов в приложении Flask, которое следует сервис-ориентированной архитектуре?

...