2

I'm trying to delineate the responsibilities between client & server. I have the server parse a file, and then send back the uncategorized accounting transactions. The URL looks something like:

POST /api/accounts/:account_id/transaction_file // used for the upload
GET /api/accounts/:account_id/uncategorized // gets all the uncategorized accounts

Now, where it gets iffy is after I've categorized those accounts on the client-side, does it make more sense to send a POST back to:

POST /api/accounts/:account_id/uncategorized

Or should the client be responsible for DELETE-ing the uncategorized transactions and then POSTing a new transaction?

DELETE /api/accounts/:account_id/uncategorized/:uncategorized_id
POST /api/accounts/:account_id/transactions

This process seems to align much more with the answer found here.

However, it does feel "wrong" that the client should be the one owning this responsibility. Am I wrong to go about it this way?

3
  • 3
    Common sense suggests that the client should not have to send a DELETE then a POST. If it does, the probability of a lost transaction increases. There is also a situation where the transaction disappears for a moment and re-appears, if anyone reads this data before the client sends the POST to uncategorized. You could post to /categorized or to /transactions without doing a DELETE. – joshp May 24 at 15:34
  • 4
    @joshp other option I didn’t think about would be a PUT that would just categorize the transaction on the server. Since it’s already assigned an ID. – keelerjr12 May 24 at 15:37
  • If you can use PUT, that makes sense. It's a single action. – joshp May 24 at 17:15
4

I would favor a PUT verb on the transaction endpoint to manually set the transaction category, as @keelerjr12 suggests..

However, you need to have a clear understanding about the transaction categorization workflow. I presume that categorization is a heuristic algorithm, so it might be unable to find a category, and it might also err by assigning an incorrect category.

  • Is the automatic categorization of newly posted transactions synchronous or asynchronous? If async, you probably need two different "uncategorized" markers, one meaning that the categorizer didn't look at the transaction yet, the other meaning that it couldn't categorize the transaction.
  • Can the client change the categorization at any time, or can it only categorize transactions which couldn't be automatically categorized? If the latter, you need some other way of fixing incorrect categorizations.
  • Or are newly entered transactions always uncategorized? Then it looks like you're introducing an unnecessary complication by the back-and-forth communication.
  • If there is no heuristic for automatic categorization, you might as well refuse to accept uncategorized transactions from the start and require the client to send properly categorized transactions at all times.
3
  • The process is that the user submits a transaction file. Each transaction gets categorized if possible. If not, then the user can view the uncategorized transactions and manually categorize them himself. Yes, later he can recategorize it. – keelerjr12 May 24 at 16:49
  • Oops my bad, I didn't realize that you're the OP when I read your PUT comment :-) – Hans-Martin Mosner May 25 at 3:53
  • To make assigning and changing categories consistent from a back-end viewpoint, I would use end-points like GET /api/account/:account_id/transactions/?uncategorized or GET /api/account/:account_id/transactions/?category=none to get the uncategorized transactions. Then you can do a PUT, POST or PATCH (e.g. POST /api/account/:account_id/transactions/:transaction_id) to store the changed category for each affected transaction. – Bart van Ingen Schenau May 25 at 13:10

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.