RESTful Backend - How coupled should my back end and front end be?

Question

I'm creating a web application with a front end client written in angular as well as a back end that I'm writing in Django (there are reasons I picked the frameworks but they are irrelevant to my question).

I have my front end planned out down to every page that will be available. I currently am only going to implement the angular cient but in the future I plan on implementing a native android and iOS app for learning purposes.

My question is how coupled should my back end design be with my front end client?

Should I design my endpoints on a per view basis? This seems like back end will need work when I create another client.

Or should my endpoints be more focused around exposing CRUD functionality for my models? This seems like it would leave room for creativity and make the back end more flexible.

These are a few of the questions I have been asking myself and I provided them to add a little more scope to my question.

Even if I went with the crud approach it seems like I will still be implementing specialized endpoints for handling common application features.

Thanks in advance.

Answer 1

If each client you intend to service requires different output from your back end. Then write your back-end in a way where is can serve each type.

Do some abstraction. Ask yourself, what things will all clients need the same way, and what things will each client need in a specific different way.

Put all the stuff that is the same for all clients together, and then write an interface for each client that handles the differences for that client. These interfaces will get all content from the same module, but adapt serving that content to the specific clients needs.

Answer 2

You should design your backend around the resources you are exposing from the backend.

These do not have to match up exactly to your model (the exposed resources and the internal model are two separate things), but often you will have a lot of overlap. For example you might have a "user" model object and a "user" resource exposed by the server.

A "resource" is an abstract concept, but it is important to have in your head what resources your server exposes to clients.

Once you have figured that out writing the client should be a doddle since the client simply requests the resources and does something with them.

To give an example of where resources and domain model don't necessary completely over lap imagine a server that exposed a "student" resource to clients, but in the domain model there were actually 10 different objects that went into creating that resource (none of them called 'student')

So the resource url for a student looked like "/students/[id]" but when that was accessed the server created 10 different models, from Person to Grade, to School in order to build that single resource.

A lot of web frameworks, such as Django, map resources very closely to domain model which can make things easier (eg /students/[id] maps directly to a Student object in the model), but it is important to remember that this is not a requirement or sometimes not even a good idea.