Architecture for untrained software engineers (Python)

Sounds like you're trying to fit a square peg into a circular hole. Tbh I think these architectural models are worthless, but if you're going to use them, treat them as very big picture, abstract buckets.

Just focus on the flow of data. First, your client sends some data to your rest endpoint (what kind of data? What format?). Your endpoint handler takes that, deserializes it into something that (what specifically?) you can use, you do processing (what?) , return some data (what?).

I'm not qualified to comment specifically on networking stuff as I don't do any of that regularly. However, I will say that the best way to learn is to do it wrong, and then figure out how to fix it. I've sometimes written the same program 5 or 10 times (over many years) before being happy with it. Each time I improve it, I'm able to do more with it or add more useful features to it.

Eventually you start to see patterns that you can reuse. These are not as formal as you get from the Design Patterns book, or whatever, but you learn the basic way to model a particular type of program, and you start to learn where each potential choice in the design can be improved for the particular case you're working on. Soon you can sit down and say, "I'm going to need a program that does x, y, and z. I know that I'll be dealing with a, b, and c, so I need to make sure I do m, n, and o." But it takes trying the different combinations to figure that out. (And also reading, etc.)

I used to be highly involved with the Stack Overflow Code Review website. Once you have your code working, I recommend posting it there for further insight into how it could be improved. You can either post the whole thing, or focus on a specific class or file you'd like to improve. (Just be sure to read the rules. Whatever you post should be compilable/runnable by someone trying to review it.)

I wrote a big long response, but I figured that since my way of doing things are so different than the ways you have learned, It would be better not to confuse you. But I do have some advice.

Don't worry about the repository. From the description you gave us, I see no reason to include one unless you're looking to log data. And even then you might not need to use a database - it can be any data store, even a text file. But then again, I am not sure if you've given us the full scope of your project.

Use Cases are typically supposed to be real-world. Something like "An accountant uses our system to find a customer's account balances".

Don't worry too much about trying to apply different structural systems. You should really understand a number of different design patterns because they all have their strengths and weaknesses. When it comes to large projects, there's usually a lot of exceptions to explicit design rules in practice. This project is relatively simple, so you might not even need to bother with these huge enterprise-grade structures. Heck, you might not even want to use Flask - It's a very large hammer to drive this very small nail with. But then again, since this is a learning project, that might go against the very reason why you're building this to begin with.

I haven't worked in Python a whole lot, but I've done a bunch of REST (and pesudo-REST :p) APIs in Java, C#, and Javascript. The architecture of them are all usually very similar, with some changes made to accommodate the use case. The terms for each architectural layer also change depending on what language/framework you're in and whatever vocabulary your team is familiar with. In the end, as long as you can say "thingymadoodle" and everyone agrees what that means, that's more important than it being "correct".

Most of the REST APIs I've worked on had an architectural plan something like this:

• Controller/Receiver: responsible for receiving the REST requests. Most basic validation and sanity checking is often handled by whatever framework (Spring, .NET MVC, etc) is in place. Further custom validation is generally done here as well. eg: "X param is required", "Y param must be between 1 and 100", etc. Controllers should only talk to Managers or Repositories, should not have business logic in them, and should not talk directly to a DB.
• Managers/Adapters (optional) : if the application needs business logic of some sort, this is generally where it happens. So doing math on currency, applying coupons to shopping carts, etc. If the REST API is pretty dumb and doesn't have logic, this can be left out (or added later). This layer is also useful if you have a single request that needs to do multiple operations, such as update a user, then save a new piece of data, and then also send an email.
• Repository/Persistence : This is usually the layer right in front of an ORM of some sort, but there's no reason it can't be a facade for another network request to some other service. This layer should only be responsible for storing/retrieving data. Validation of the request, security checks, and logic should not be put here.

So these are the layers. All of the "rules" I stated in each layer are "soft". They should be followed right up until they don't make sense. The point is less to be strict, and more to follow a convention, until someone presents a reasonable argument to depart from the established pattern. Some other things you've mentioned:

• filtering all objects by ID could be done right before returning to the user, but might be more efficient to ask a DB engine to do that for you.
• Serializers and de-serializers I would expect to find in the Controller/Receiver layer. Obvious exception being if some parts of your Persistence layer is a facade to another API, it will need to serialize/de-serializers things in order to communicate.

One thing I personally advocate for in most APIs that I've built, is to have the team deliberately separate the domain model from the API. By this I mean, if you had a DB with a Customer table/object, the ORM class should NOT be the class that is serialized and returned to the user. Reason being, it combines two separate concepts into a single class. The domain model is how you the developers think about and manipulate your data. The user usually doesn't need that data, or needs it formatted differently. Separating the two from the beginning allows each to evolve separately, even though there's extra overhead involved mapping the domain model to the API before returning the user's request.