0

I want to understand what should be the right request/response structure and API design to solve below problem. I have 2 entities let say Abc and Xyz. And Xyz has a foreign key of Abc. So, to create a record for Xyz, there has to be mapped Abc record.

Now for request structure point of view, I need to create one POST request for Abc that is like

POST /Abc

This is pretty much straightforward. But the problem is with Xyz. The requirement is whenever a user came for to create Xyz, he may also request to update the attached Abc record, too. For example, I have created a record for Abc with id 5. Now, whenever I want to create a corresponding Xyz record, I will request to update the Abc record with id 5 and create a new Xyz record for this foreign key. So, PATCH /Abc and POST /Xyz But the client requests only once and share whole data on single URI.

So, what is the right way to handle multiple HTTP methods on single URI? Should I create POST request or PATCH?

I couldn't create 2 requests because the client wants this process as transactional.

Todd
  • 30,472
  • 11
  • 81
  • 89
mehtas
  • 49
  • 1
  • 8

1 Answers1

0

Firstly I guess you should think this

I couldn't create 2 requests because the client wants this process as transactional.

in an other way. As I see it the requirement for transactional might just mean - I might be terribly wrong on this so find out the truth - that when there is also an update to Abc the process of creating a new Xyz is transactional with updating Abc. So the Xyz is not created if the update for Abc fails (or vice versa) and some error is returned.

So you might be able to create two endpoints:

  • one with just POST:ing a new Xyz
  • another for creating a new Xyz and update Abc at the same time transactionally

So you might be able to create two endpoints. More interesting here is that is the latter POST or PATCH? It seems to somehow be both, yes.

However see - for example - this question & accepted answer, there is about PATCH:

The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI

Now, the following question is that is the changed Abc identified by the Request-URI? If not then it is - as I understand this - a POST.

Which means you should need only one POST endpoint that checks if there is a need and does transactional updates id needed. But maybe it would still be better to have separate endpoints.

pirho
  • 11,565
  • 12
  • 43
  • 70
  • So, for 2 endpoints the situation is pretty much clear and hence the solution, too. But here the issue is I want just a single end-point. So, there may an issue with its response code too. That PATCH /Abc is successful but POST /Xyz is not. How to handle those? And related to your question of change of Abc is identified by URI or not? That's up to us as the front-end (client) just deals with the end result. My preference is YES but I will happy to adopt a robust solution. Just one constraint is, there is just 1 API call and I have to perform 2 trans. – mehtas Jan 06 '19 at 09:52
  • Well I stated _Which means you should need only one POST endpoint_ so I think you should not create two. So about the _identified by the URI_ I left it to you to decide but if you "POST" a new `Xyz` is it not so that the changed `Abc` is a part of the new `Xyz` and you might not necessarily identify `Abc` in the URI? So **not** something like `POST(or PATCH) /Xyz/{alteredAbcId}/Abc` but just `POST /Xyz` where `Xyz` contains altered `Abc`? – pirho Jan 06 '19 at 10:03