0

I'm thinking about a REST API design. There are several tables in my database. For example Customer and Order.

Of course - each Order has its Customer (and every customer can have many Orders).

I've decided to provide such an interface

/api/v1/Customers/ -- get list of Customers, add new Customer /api/v1/Customers/:id: -- get Customer with id=:id: /api/v1/Orders/ -- get list of Orders, add new Order /api/v1/Orders/:id: -- get Order with id=:id:

It works flawlessly. But my frontend has to display a list of orders with customer names. With this interface, I will have to make a single call to /api/v1/Orders/ and then another call to /api/v1/Customer/:id: for each record from the previous call. Or perform two calls to /api/v1/Orders/ and /api/v1/Customers/ and combine them on the frontend side.

It looks like overkill, this kind of operation should be done at the database level. But how can/should I provide an appropriate interface?

/api/v1/OrdersWithCustomers /api/v1/OrdersWithCustomers/:id:

Seems weir. Is it a right way to go

Improve this question
3
  • Either ditch the REST API and build a GraphQL API or use join Commented Jan 16, 2021 at 12:04
  • I would like to use join on SQL side. I just do not know how to expose this API on REST level. Commented Jan 16, 2021 at 12:05
  • sThere is no reason to have separate end points. What I am saying is /api/v1/Orders/ should return objects with customer fields already resolved, if you need them. Commented Jan 16, 2021 at 12:06

3 Answers 3

Reset to default
1

There's no rule that says you cannot "extend" the data being returned from a REST API call. So instead of returning "just" the Order entity (as stored in the backend), you could of course return an OrderResponseDTO which includes all (revelant) fields of the Order entity - plus some from the Customer entity that might are relevant in your use case.

The data model for your REST API does not have to be an exact 1:1 match to your underlying database schema - it does give you the freedom to leave out some fields, or add some additional information that the consumers of your API will find helpful.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Great question, and any API design will tend to hit pragmatic reality at some point like this.

One option is to include a larger object graph for each resource (ie include the customer linked to each order) but use filter query parameters to allow users to specify what properties they require or don't require.

Personally I think that request parameters on a restful GET are fine for either search semantics when retrieving a list of resources, or filtering what is presented for each resource as in this case

Another option for your use case might be to look into a GraphQL approach.

Improve this answer

Comments

0

How would you do it on the web?

You've got a web site, and that website serves documents about Customers, and documents about Orders. But your clients aren't happy, because its too much boring, mistake-prone work to aggregate information in the two kinds of documents.

Can we please have a document, they ask, with the boring work already done?

And so you generate a bunch of these new reports, and stick them on your web server, and create links to make it easier to navigate between related documents. TA-DA.

A "REST-API" is a facade that makes your information look and act like a web site. The fact that you are generating your representations from a database is an implementation details, deliberately hidden behind the "uniform interface".

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.