0

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

  • what is the question? How to implement a shop without having a shopping-cart? – k3b Aug 19 '17 at 7:38
  • @k3b well, there's a paragraphs starting with "let's get to the question". But basically the question is whether REST is suitable for such problems, despite the overhead and "hiding" lots of resources from user or is there a better pattern for complex APIs? – pzaj Aug 20 '17 at 9:45
  • 1
    REST seems perfectly suited for this use case, as it is basically a state machine from choices to purchase right up to order confirmation. I'm not quite sure what the issue is, but possibly from your comment that this would require the creation of 'hidden' resources you might be tying your database elements too closely to your resources. Remember database elements and resources can have as little to do with each other as you like. One resource might use data from multiple tables, or no tables at all. – Cormac Mulhall Aug 24 '17 at 0:05
  • @CormacMulhall I think this is by far the most meaningful comment so far, although it does not answer the question, it does point out a very important aspect of REST. – pzaj Aug 24 '17 at 17:26
2

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.

  • this is mostly right :) I currently have a monolithic app that eventually I'd like to re-factor into 12-factor app (or set of apps, since I have few apps already). At the moment I'm looking to make the 1st step by making it use API (separate front-end & back-end). This is to allow easy building of mobile app for example. I can easily turn some cases to be RESTful due to natural resource behaviour. But with given example it does seem confusing & bringing a lot of overhead. – pzaj Aug 20 '17 at 9:49
  • oh and I forgot completely - thanks for the links :) I will definitely check them out. I actually know the theory behind microservices (just like I know theory behind REST, SOAP, etc.), but I have trouble picking right patterns / architectures and taking them from theory to practice :) – pzaj Aug 20 '17 at 13:05
  • 1
    Good luck with the architecture design. It can be rather challenging, especially determining where the boundaries are. – Andre Platov Aug 22 '17 at 0:19
  • I like separate backend/frontend too, especially for complex apps. – Andre Platov Aug 22 '17 at 0:26

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.