Handling Routes on Business Logic with Similar path

REST
1

Hi,
I have 2 similar API routes on my business logic like this:

  • Get todo detail :

/todos/{todoId}

  • Get list of inompleted todos:

/todos/incomplete

But everytime I send request to /todos/incomplete, it will go to Get Todo detail instead of Get list of incompleted todos.

Is there any ways to manage this, such as set priority on which route will be checked first?

Thank you.

1 Like
2

Hi @irwancheung,

Just swap the methods.

Cheers,
Stanislaw

3

Hi, @stanislaw.grin Could you please explain in more details? I don’t understand of how to do it.

4

Your service methods are in the following order now:

class TodosService {

  /**
   * @route GET /todos/{id}
   * @returns {Promise.<String>}
   */
  getTodo() {
    // method implementation...
  }
  
  /**
   * @route GET /todos/incomplete
   * @returns {Promise.<String>}
   */
  getIncomlete() {
    // method implementation...
  }

}

Backendless.ServerCode.addService(TodosService)

For the method getIncomlete to work, you need to swap them, then it will become priority:

class TodosService {

  /**
   * @route GET /todos/incomplete
   * @returns {Promise.<String>}
   */
  getIncomlete() {
    // method implementation...
  }
  
  /**
   * @route GET /todos/{id}
   * @returns {Promise.<String>}
   */
  getTodo() {
    // method implementation...
  }

}

Backendless.ServerCode.addService(TodosService)
5

I have answered for case if you use JS for your logic. Maybe you are using Codeless for your business logic?

6

Yes, Im using Codeless. Is it possible to do that too?

7

This is a bit of a tricky one, but it’s possible! You need to rename the getTodo method to any other name (lets say getTodo2), and then rename the same method again to getTodo.
Let my try to explain why it works. When you use codeless, a JavaScript service is generated under the hood that looks very similar to what I wrote above. And the methods that are in it are exactly in the order in which they were created, and then each edit of the method “lowers” this method to the end of the list. Thus, by renaming the method back and forth, you will change their current order and the priority will become correct.
It is worth noting that changing the logic of the methods itself will not entail changing their order, so you can safely change the internal logic and not be afraid that the priority of the methods will be lost.

Let me know if it works for you!

Cheers,
Stanislaw