Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Pass Throughs and End Points

Extracts from your examples


is this example (I changed users to phone)

Case NextSegment _EQC 'phone'
// NextSegment contains the name of another service. The RemainingURL must be updated to show that the
// NextSegment is not longer a part of the RemainingURL. Then the RunHTTPService service should be called.
RemainingURL = Field(RemainingURL, '/', 2, 99)
HTTP_Services('RunHTTPService', NextSegment, RemainingURL)

because I was wondering when the phone service is called, how does it get 5678, or, is the code completely different in this case, and you need to do what Mark did, and frame the HTTP parameters.

Is there a relevant example in the online help. (sorry, not sure what I should be searching for)


  • >>HTTP parameters.

    Meant HREFxxxxx
  • Much of this depends on where you choose to define the endpoint. There is no "best practice" here, it really depends on what makes the most sense for your application design and maintenance.

    /customers could be your endpoint and all other segments are merely additional arguments that you can parse (like Mark's suggestion) and use as needed. In this design, you don't call any other services. You just create your routing block at the top to handle each unique scenario. It's your API so you get to decide what each segment means and what to do with it.

    /phone could also be an endpoint. In this design, /customers would need to call the /phone service directly. However, since your customer's resource ID is located in the section of the URL before you reach this endpoint, you'll have to parse the full endpoint URL to get the data you need. In my opinion, having a dedicated /phone endpoint (service) is overkill so I would recommend the previous idea, but I can't say one is right and the other is wrong.

  • Sorry Barry,

    I may have added to the confusion with the inclusion of the HREF stuff in my other post. It wasn't relevant to the topic at hand, it just happened to be within the code segment that I copied and pasted and I didn't remove it before posting.

    I'll also reiterate something I mentioned earlier and that is I don't know if anything I'm doing is right or best practice; just kind of sharing it as food for thought.

    Here's some more though, which may give you some ideas.
    These are some of the urls from the previous post
    Give me a list of the people who work for that client

    Give me details about a specific team member

    Give me the photo of that team member
    In each of those, "clients" is technically the endpoint however I also have an "employees" service which acts as an endpoint for different requests. Those requests include

    Give me details about a specific employee

    Give me a photo of a specific employee

    Why do I mention those?
    Glad you asked.

    From the original urls, a clients team is actually a group of employees so internally the team branch within the clients service actually just calls the employees service passing the remaining url. The logic therefore just flows the same as if the employees service was called directly.

    In other words, the incoming request is

    Within the clients service, the team branch just calls
    response = http_employees_services(remainingurl ) where the remainingurl is now "{memberId}/image"

    In summary



    produce the same result.
Sign In or Register to comment.