Skip to main content
arthuro2392
arthuro2392
October 19, 2022
Question

Is there a way to have an API with same endpoint and method, but different Path?

  • October 19, 2022
  • 3 replies
  • 0 views

Good day,


I have some APIs that do operations over the resource 'User', and the following ones are needed:

GET users - To retrieve them
POST users - To create them
PATCH users - To update them
PATCH users/disable - To disable them
PATCH users/enable - To enable them

The problem is that I can only have one combination of endpoint vs method, so when I try to declare the second PATCH user API to specify the path to "disable" or "enable" I receive and error.


My question is: what's the Appian way for doing those APIs declarations using the Restful pattern?


Create only one web API object switching between each different path?
Let the endpoint be empty, and put all the URI in the path field?
Other options...

Thanks for the help in advance

3 replies

stefanhelzle0001
stefanhelzle0001
Brainy
October 19, 2022

Sure. The path is available as parameters in the API. You would just have to map the path to your respective logic.

    arthuro2392
    arthuro2392Author
    October 20, 2022

    So, if I have

    PATCH users
    PATCH users/disable
    PATCH users/enable
    PATCH users/addresses/{id}
    PATCH users/phone-numbers/{id}
    And so on...

    I'll need to have a bunch of IFs, or maybe a decision table-ish structure, inside a single Web API object to do the routing.

    This is kinda limitating and frustrating as the endpoint cannot have a "/" for inner resources declaration and the path doesn't help with that.

    If there's a main resource with a lot of inner resources, the object will very packed.
    Well, it is what it is.

    Thanks for the answer, Stefan.

    stefanhelzle0001
    stefanhelzle0001
    Brainy
    October 20, 2022

    I implement this in a way that the API calls a dispatching expression which uses match() to call individual expressions based on the path. Forward the http object to the next expression for flexibility.

      Terms & ConditionsAccessibility statement