3 ms·

Good question. If you consider each API endpoint a very specific serialization of a model, are the serialization parameters considered part of the model itself?

Good question. If you consider each API endpoint a very specific serialization of a model, are the serialization parameters considered part of the model itself? (I would consider them such, and decided to approach the development with that in mind.)

cheald 12y ago
I don't think so. The data as presented to the user through the API is a view concern. The model should never, ever know or care about how it is presented; serialization (which is used to marshal the data as a whole for transport and reconstitution) and presentation (which is used to transform the data into some form acceptable for consumption by an external entity) are separate processes with separate goals. I think you've conflated serialization and presentation here; if I can't reconstitute the whole object from the serialization provided, then it's not a serialization, it's a presentation. A valid presentation might be "the serialization of this object", but "a subset of this object suitable for display" is not a valid serialization.
- keithwhor 12y ago
  Good points. I think it boils down to an issue of semantics, though. FastAPI effectively eliminates (or hides) the View layer by allowing the Model to determine which fields it should allow the View to access. If you don't believe this is explicit enough (which could be a fair argument!), it's perfectly reasonable to suggest this "breaks" standard MVC conventions (as it can easily be construed as the View being part of the Model!). I would argue that it merely allows for more automated (albeit implicit) generation of a View. The goal here was to simplify the API endpoint creation process for the vast majority of use cases, and provide a standard output that could be easily recognized and consistently managed by any external software.
  - cheald 12y ago
    Well, it certainly meets those goals, but it does so by putting view logic into the model layer. You might take a look at the Presenter pattern; Draper is an excellent implementation of it, which permits for this kind of "model-attached" view behavior, while maintaining proper MVC separations.

cheald 12y ago

I don't think so. The data as presented to the user through the API is a view concern. The model should never, ever know or care about how it is presented; serialization (which is used to marshal the data as a whole for transport and reconstitution) and presentation (which is used to transform the data into some form acceptable for consumption by an external entity) are separate processes with separate goals. I think you've conflated serialization and presentation here; if I can't reconstitute the whole object from the serialization provided, then it's not a serialization, it's a presentation. A valid presentation might be "the serialization of this object", but "a subset of this object suitable for display" is not a valid serialization.

keithwhor 12y ago
Good points. I think it boils down to an issue of semantics, though. FastAPI effectively eliminates (or hides) the View layer by allowing the Model to determine which fields it should allow the View to access. If you don't believe this is explicit enough (which could be a fair argument!), it's perfectly reasonable to suggest this "breaks" standard MVC conventions (as it can easily be construed as the View being part of the Model!). I would argue that it merely allows for more automated (albeit implicit) generation of a View. The goal here was to simplify the API endpoint creation process for the vast majority of use cases, and provide a standard output that could be easily recognized and consistently managed by any external software.
- cheald 12y ago
  Well, it certainly meets those goals, but it does so by putting view logic into the model layer. You might take a look at the Presenter pattern; Draper is an excellent implementation of it, which permits for this kind of "model-attached" view behavior, while maintaining proper MVC separations.