Basic REST API concepts

user_14183856 0
Viewed 58

I'm trying to develop a REST API for the first time and it seems to me that I have a problem with realizing some basic REST API concepts. I'm not sure if I should only create CRUD operations for each model and then analize responses from these operations using Vue (in my case)? Or should I let my DRF side do some business logic?

SPECIFIC QUESTION Here's an example. I want to remove an object and update some other objects in other table, which are related to the original object I would like to delete. Should I just create one POST(?) endpoint to do that or should I get those other objects I would like to delete using Vue, then call "delete" on each one of them from Vue, and only then delete the original object. As you can see in first case it's a complex operation and in the second case it's a couple of CRUD operations.

I'm asking this because I found many interpretations of REST API in Google and I struggle to find the truth. It seems to me that DRF doesn't want me to create complex views, looks like it just wants me to create 4 operations for each model. Hope I made myself clear, thank you for trying to help.

django-rest-framework rest
1 Answers

What you really seem to be asking is what degree of coupling is appropriate for a REST API. The answer is as little as possible, but what's possible will depend on your application and your requirements.

To use your example, yes, it's preferable to have a uniform interface for deletion for each one of your resources, but what are your other requirements? Is it a problem if you cascade the deletion of children resources? Is it OK for you to automate deletion of orphan resources? Can you afford to lose transaction integrity by requiring the client to explicitly delete multiple resources through their own endpoints? If you can't find a way to make the uniform deletion interface work for you, there's nothing wrong or unRESTful in creating a single POST endpoint for doing what you need, as long as that's not coupled to the needs of a particular client implementation.

Don't expect to find "the truth", or a manual of best practices for REST API or final answers to your questions about that, because REST is just an architectural style, not a rigid specification for architectures. It's just a set of principles used to guide long-term design and evolution of applications.

If you don't have long-term requirements that ask for a careful adoption of REST principles, more important than finding the truth about REST is to respect the Principle of Least Astonishment, since many people already have strong opinions about how a REST API should be implemented. A good example is API versioning with URLs. Adding a version number to your URLs is a REST anti-pattern, but it's a widespread practice believed by many to be a REST best-practice. That happens because most so-called APIs are strongly coupled to the clients, and the API versioning makes it much easier to make backwards incompatible changes. Making backwards incompatible changes is not a problem when you implement REST API and clients correctly, but it takes a lot more work than simply tackling a version number somewhere.

If you really have long-term requirements or if you are genuinely interested in learning about how to design and implement a REST API correctly, try searching for "Hypermedia API" instead of "REST API". Many people gave up on the term REST and decided to start using a new term to refer to APIs that implement REST correctly.

user_12024210
Related