Pass Throughs and End Points

BarryStevens

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)

BarryStevens

>>HTTP parameters.

Meant HREFxxxxx

DonBakke

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.

AusMarkB

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
api/clients/{clientid}/team

Give me details about a specific team member
api/clients/{clientid}/team/{memberId}

Give me the photo of that team member
api/clients/{clientid}/team/{memberId}/image

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.