0

In my application, I have resource A that is super class and A1, A2 that inherits A and other properties that are specific to them. A cannot exist by itself, it must be either A1 or A2. This is a classic example of hierarchical schema. I want to design an API that will return resource A with its subclass properties as well. Our application is currently designed as two separate database tables A1 and A2 and their primary keys are auto increment sequence numbers. So if I have to retrieve a resource of type 1, API path must be /A/{A1-id}?type=1. I do not like passing type as query parameter because its part of a key that identifies the resource and it is not a filter. Based on the type, the application will know if it has to query table A1 or A2 to return the data.

  • I do not want to have sequence numbers starting at different number for both tables.
  • I considered translating common properties into table A with single ID for both types. A1 and A2 will become just association tables. But that will be a lot of code change.
  • Also considered converting sequence ID in both tables to UUID and the application will always query both A1 and A2 each time it receives a request, but feels like level is still required when update is done or it should find the table first and then update the table in separate queries instead of directly updating the table.

What is the best way to solve this? Can we have /A/{id}/{typeid} to avoid making lots of code changes ? I know we are not being pure RESTful because this API is for Angular MVC and will not be exposed to external users.

  • "I do not want to have sequence numbers starting at different number for both tables." - what if they're not sequence numbers? Make the IDs A1_{seq} and A2_{seq}? – immibis Aug 11 '16 at 4:19
  • 1
    What is the use case from the api consumer? That is in my opinion what you should focus on first. You now start with your existing code structure but that does not necessarily reflect the use case as the consumer. Your hierarchy might just be an implementation detail. – Luc Franken Aug 11 '16 at 10:33
2

In my application, I have resource A that is super class and A1, A2 that inherits A and other properties that are specific to them. A cannot exist by itself, it must be either A1 or A2

Given this restriction, the most logical implementation would be to have 2 API paths:

  • /A1/{A1-id}
  • /A2/{A2-id}

As the caller has to know if he gets an A1 or A2 object and what type of object the id refers to, there is not really a point in accessing both A1 and A2 resources through the same API path.

You could consider adding a read-only /A/ API path to get a mixture of A1 and A2 objects based on some search criteria.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.