Help needed with class inheritance in our new SPA
I’m working on a project where we’re moving from a static HTML site to a Single-Page App. We’re stuck on how to handle object types from our API.
Our PHP backend adds a _type field to JSON exports to show the object’s original class. This works for subclasses, but we also need to know about parent classes sometimes.
Here’s our setup:
Animal
Mammal
Human
Dog
Reptile
Crocodile
Snake
When we GET /animals/, we get a list of different animals. But how do we know which ones are mammals?
We thought about adding an inheritance chain like this:
{
"_type": "Human",
"id": 10,
"food": "Pizza",
"_parentClasses": "Animal.Mammal.Human"
}
It’s simple to do, but I’m not sure if it’s the best way. What do you think? How have you dealt with this kind of thing before?
As someone who’s worked on similar projects, I can tell you that handling inheritance in RESTful APIs can be tricky. Your idea of adding a ‘_parentClasses’ field isn’t bad, but it might lead to bloated responses, especially with deeper hierarchies.
One approach I’ve found effective is using a combination of the ‘_type’ field and separate endpoints for class relationships. For example, you could have a ‘/mammals’ endpoint that returns all animals of that type. This keeps your main ‘/animals’ endpoint clean while still allowing clients to fetch specific categories when needed.
Another option is to implement a query parameter system. So a GET request to ‘/animals?type=mammal’ would return all mammals. This gives you flexibility without complicating your base response structure.
Remember, the goal is to balance providing necessary information with keeping your API responses lean and efficient. Don’t be afraid to iterate on your design as you learn more about how your front-end actually uses this data.
I’ve faced similar challenges in RESTful API design. While adding a ‘_parentClasses’ field is straightforward, it might not be the most efficient approach for complex hierarchies. Instead, consider implementing a ‘type’ field with a more specific identifier, like ‘mammal.human’. This maintains the inheritance structure without cluttering the response.
Another option is to use content negotiation. By accepting different media types, clients can request either a simplified or detailed representation of the resource. This allows you to serve basic information by default and provide full inheritance details when explicitly requested.
Ultimately, the best solution depends on your specific use case and how the client will consume this data. If you frequently need to check for parent classes, including them in the response might be justified. Otherwise, keeping the API response lean and handling inheritance logic on the client side could be more maintainable long-term.
hey, have u thought about using a nested object approach? like this:
{
"type": {
"class": "Human",
"parent": "Mammal",
"grandparent": "Animal"
},
"id": 10,
"food": "Pizza"
}
This way u keep the hierarchy clear without messin with long strings. just an idea!