RESTful APIs vs complex processing - an alternative

Question

I hope I've chosen the right community for that (there's no software architecture / design one)!

I'd like to ask you about practical considerations of RESTful APIs (and similar design patterns as for that matter) in context of complex server-side operations / business logic.

Few things to keep in mind:

1. I know REST is not the only way to go nor the silver bullet
2. I couldn't find any design pattern / practice that would let me keep the API structured (like REST does) and make it sensible for what I need to do.

I think it's going to be much easier if I give you an example, so here we go: I'm facing a business logic that spans multiple steps. The steps are:

1. User make various choices and submit them (let's say they are using HTML form).
2. These choices are validated for being both up-to-date (with database state, e.g. some options may no longer be available at the time they are submitted) and against themselves (because you can only have certain combinations of options put together).
3. If everything is fine, some database updates are made (e.g. to create a pre-order of limited goods for that user).
4. User is then given the response (let it be HTML form for now) containing information that let them complete another step by making even more choices - let's say they should pick their method of payment for previously pre-ordered goods.
5. They submit their choices again, in response they receive information that will let them complete their payment.
6. And here it starts to get ugly...

While up to point 5 I am able to identify REST resources, etc. It gets really hard to process further steps. Why? Because once the user completes the payment (one way or another, doesn't matter), they will receive URL of my API endpoint that should verify the payment, process the pre-order into the actual order and return confirmation to the user. Which in case of REST should be (the confirmation) a resource. This is fine, but having in mind the process of turning pre-order into an order means creating multiple resources of different types, it means we "hide" these resources from the user.

Basically, there's a lot of things going on under the hood and they should probably be returned in a confirmation. The problem is, there's no confirmation anywhere in the database.

But well, let's get to the question - is there any design pattern, framework, architecture more suitable to that kind of problems?

Sidenotes:

1. I said there's no confirmation in the database - I have a monolithic app that I'd like to turn into API-based application to decouple back-end and front-end.
2. I'm also concerned about performance. I believe this could be ultimately done the RESTful way (although may be hard without keeping the state), but that would mean making the simple API for complex problem, resulting in a lot of API calls to achieve the same effect.

EDIT

Another thing that concerns me and make me go against RESTful API is that it would require these multiple API calls to complete the whole process acting on resources, which would mean any client app utilizing this API would have to re-implement the same logic as opposed to encapsulating this logic on server-side

Answer 1

Very good question.

I sounds like you have a monolithic application that you would like to re-factor into a set of smaller applications using api-based design for the "backend" code. It also sounds like the idea of using REST is appealing to you, which is not a bad thing since it is very popular and sometimes refers to one of the standard ways to integrate multiple systems/apps.

Check out "Microservices" architectural pattern. Good place to start would be an article by Martin Fowler. If you feel like exploring it further, I can recommend a very good book by Sam Newman - Building Microservices. The book is a more comprehensive resource, and even has a chapter on splitting a monolithic application.

hope this helps.