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
/api/customers/5678/phone/work
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)
/api/customers/5678/phone/work
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)
Comments
Meant HREFxxxxx
/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.
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 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
api/employees/{empid}
Give me a photo of a specific employee
api/employees/{empid}/image
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
api/clients/{clientid}/team/{memberId}/image
Within the clients service, the team branch just calls
response = http_employees_services(remainingurl ) where the remainingurl is now "{memberId}/image"
In summary
api/employees/{empid}/image
and
api/clients/{clientid}/team/{memberId}/image
produce the same result.