Настой организовать зефир схемы - PullRequest
Новая
       55

Настой организовать зефир схемы

0 голосов
/ 01 ноября 2019

Я разрабатываю API в Flask framework, и он становится все больше. На данный момент у меня есть десятки sqlalchemy моделей и даже больше Marshmallow CRUD-схем.

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

  • вложенный ответ json 
/v0/user/all

{ 
   "data":{ 
      "id":1,
      "name":"foo",
      "phone":"927487286",
      "courses":[ 
         { 
            "id":12,
            "name":"Math",
            "place":{ 
               "id":1,
               "location":"Foo Street"
            }
         }
      ]
   }
}
  • может использовать схемы, которые былииспользуется в другой конечной точке, но с разными полями 
/v0/courses/{id}

{ 
   "data":{ 
      "id":12,
      "name":"Math",
      "place":{ 
         "location":"Foo Street"
      }
   }
}

Я думал о реализации метода to_dict в моих моделях, но его также сложно поддерживать, когда дело доходит до вложенности в другом сериализаторе.

Любой совет?

1 Ответ

0 голосов
/ 10 ноября 2019

Смысл зефира в том, чтобы избегать to_dict методов в объектах, делегируя ответственность за представление схемам. См. эту презентацию от Стивена Лории (автора зефира).

Если ваши схемы API близки к вашей структуре БД, вы можете ограничить дублирование, используя marshmallow-sqlalchemy длягенерировать схемы API автоматически из моделей.

Если схемы API слишком сильно отличаются от модели, то, возможно, лучше создать схему с нуля для каждого ресурса. Вы все еще можете использовать метод field_for из marshmallow-sqlalchemy, чтобы избежать дублирования типов моделей и валидаторов.

...