/api/funeralvaluables/16333P/123 how do I know about 123

BarryStevens

http://localhost/api/funeralvaluables/16333P/123

How do I know that 123 has been passed and not just 16333P.
I want to get just record 123 associated with 16333P not ALL the records as if was just /16333P

What is the correct coding at start of the ssp. (ie the case statement)
I am not using the new fancy srp shortcut coding.

DonBakke

I am not using the new fancy srp shortcut coding.

I'm not sure what that means.

How do I know that 123 has been passed and not just 16333P.

I'll help answer this question based on the latest version of the framework, so your mileage may vary. My first question back to you is what service are you trying to get this from? I presume HTTP_FUNERAL_VALUABLES. Please confirm.

BarryStevens

sorry I couldn't think of it at the time 'enhanced basic+' - I notice all your new examples have now used this.

ssp is HTTP_funeralvaluables_Services

i have done this but not sure if it is foolproof or recommended.

TransNo='' if index(RemainingURL,'/',1) then TransNo = RemainingURL[-1, 'B/'] end Begin Case case TransNo

DonBakke

Sorry, let me ask you one more question. Is the argument coming into your service RemainingURL? Also, in the Notes section of the comment block, do you see anything like this:

   Notes       :   All HTTP web services should include the HTTP_SERVICE_SETUP insert. This will provide several useful
                    variables:

                        APIURL                  - The base URL for the API entry point (e.g., api.mysite.com/v1).
                        FullEndPointURL         - The URL submitted by the client.
                        HTTPMethod              - The HTTP Method (Verb) submitted by the client (e.g., GET, POST, etc.)
                        SelfURL                 - The URL path representing the current service.
                        NextSegment             - The URL segment immediately following the SelfURL (if any). This
                                                  could contain the name of the next service or it could contain the
                                                  Item ID for the current service (aka resource).
                        CurrentServiceHandler   - The name of the currently running BASIC+ stored procedure.

BarryStevens

Yes it is in RemainingURL, I did a debug which is why I knew where to find it.

I do have the insert included in the compile.

BarryStevens

NextSegment has 16333P in it

BarryStevens

It all works, I get all the values!

AusMarkB

I think "foolproof" is dependent on what else you might decide to do later.
I have taken a similar approach though

If Index(RemainingURL, '/', 1) then RemainingURL = Field(RemainingURL, '/', 2, 99) NextSegment = RemainingURL[1, '/'] HREFNames := 'timecard' : @FM HREFRels := 'Details for timecard ':ItemID : @FM HREFURIs := SelfURL : '/' : ItemID : @FM HREFMethods := "GET" : @FM Begin Case Case NextSegment _eqc "cp" ; GoSub get_careplan Case NextSegment _eqc "emp" ; GoSub get_employee Case NextSegment _eqc "empimage" ; GoSub get_empimage Case NextSegment _eqc "feedback" ; GoSub get_feedback Case NextSegment _eqc "files" ; GoSub get_files Case NextSegment _eqc "hn" ; GoSub get_handovers Case NextSegment _eqc "ndis" ; GoSub get_ndis Case NextSegment _eqc "overview" ; GoSub get_overview Case NextSegment _eqc "report" ; GoSub get_report Case NextSegment _eqc "sign" ; GoSub get_signature Case NextSegment _eqc "survey" ; GoSub get_survey Case NextSegment _eqc "tasks" ; GoSub get_tasks End Case end else

I see the only difference being in how you extract TransNo.
I've applied the same logic the framework already does in determining NextSegment from RemainingURL.
Your approach limits you from ever extending the URL any further because TranNo will always be the last segment

Eg: http://localhost/api/funeralvaluables/16333P/123

will give you "123" but

http://localhost/api/funeralvaluables/16333P/123/somethingelse/morestuff/anotherthing/xyz

will get you "xyz" and you'll never know about this bit
"123/somethingelse/morestuff/anotherthing"

It's up to you to decide whether that will ever be relevant

DonBakke

Let's slow down here. First, you misunderstood the intent of my question about the RequestURL argument. Obviously I knew you were aware of it since you used it in your example. I was trying to confirm if that variable was being passed in as an argument or was it being populated another way. This was meant to help me get a baseline for the version of the HTTP Framework you were using.

Second, my expectation is that NextSegment would have 123 instead of 16333P. If you have a copy of HTTP_CONTACTS_SERVICES (which should ship with the RDK), look at the GetItem gosub section. You'll see the following:

GetItem: ItemID = NextSegment HAL = HTTP_Resource_Services('GetDatabaseItem', 'CONTACTS', SelfURL : '/' : ItemID, ItemID)

Hence, NextSegment is intended to be where the Key ID (or Resource Identifier) is located. Your code works if there is no other segment following 123...but there could be so I don't think your approach is 100% foolproof.

BarryStevens

Mark, that is spot on, I knew it was 'wrong' but not sure why.
I will never (Mmm should never say never) need extras, but, I will implement your method for at least it would give me the code should I ever need to do something as per your example in another api.

Thank you so much for your trouble.

BarryStevens

Don,

>>Second, my expectation is that NextSegment would have 123 instead of 16333P
That is what I was expecting too, but then I needed the 16333P also, so looks like it works better this way.
I know I should have passed it as /16333P~123 as I was just forming a key for DELETE, but with the developer I have I always get 'but you dont do it like that, I have to write so much extra code, you are very annoying' :)

I thought I had the latest version, just of the underlying system http_ routines MCP etc, but still my existing ones where I changed where I thought the changes were.

I know this bit was changed::)
Function HTTP_funeralvaluables_Services(RemainingURL)

AusMarkB

Sorry Don, jumped in on you there but I think we're saying the same thing.

Barry, I'm with Don on the format of the url being unexpected though.
I don't know what 1633P or 123 represents but as Don says, coming into the service, NextSegment would be the Key ID which looks ok if 1633P represents a key. If that's correct then the 123 must represent a key to another resource of some sort?

If those assumptions are correct than to be consistent and allow for further growth there should probably be some other segment between the two keys like this

http://localhost/api/funeralvaluables/16333P/anotherresource/123

Using the sample code above then my case statement would be looking for "anotherresource" to know where to branch to. In the gosub branch the same logic could apply if appropriate to then extract 123 and go from there.

Does that make sense?

BarryStevens

OK guys,
Looks like I am not using the concept properly (as usual)

I will do /16333P?transno=123

BarryStevens

Mark,

One day I will ask you about this!!!

HREFNames := 'timecard' : @FM
HREFRels := 'Details for timecard ':ItemID : @FM
HREFURIs := SelfURL : '/' : ItemID : @FM
HREFMethods := "GET" : @FM


btw: Not sure why the other post got 'cross outs'.

AusMarkB

Clarification first.
There's no guarantee I'm doing it "properly" either. It's just the approach I took.
Here's some examples of why and how

Get me a list of clients
api/clients

Give me the details about a specific client
api/clients/{clientid}

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

As you say Barry, never say never

DonBakke

I think this issue is getting muddied. I would not take the approach you are considering. I can continue to offer my advice if you wish, but it would only serve to explain a best practice approach from a RESTful point of view and to ensure consistency within your APIs. However, if you have a solution that works for you then perhaps you don't want or need me to say anything else. It might be well enough to follow the "If it ain't broke don't fix it" philosophy.

BarryStevens

>> can continue to offer my advice if you wish, but it would only serve to explain a best practice approach from a RESTful point of view

YES PLEASE!!!

DonBakke

Guys - Using angle brackets in your responses is causing odd formatting. Barry, this is why you had characters in strikeout mode. Mark, this is why your clientid tag was missing. I updated Barry's post with emoji (since I suspect that is what you were trying to convey) and I updated Mark's post with french brackets.

DonBakke

Barry - Rather than reinvent the wheel, look at the examples Mark posted. Those URLs are more RESTful because they clearly identify a unique resource on the server. I'm not sure if your database record is a single or 2-part key, but it doesn't matter from a URL perspective since URLs are not pointing to a database. They are pointing to a resource.

Now, once you know how to identify the resource (e.g., /funeralvaluables/16333P/123), all you need to do is switch the HTTP Method to indicate the action you want the server to perform. Thus:

Get (read) the resource:
GET /funeralvaluables/16333P/123

Update (write changes) to the resource:
PUT /funeralvaluables/16333P/123

Delete the resource:
DELETE /funeralvaluables/16333P/123

Create a new resource:
POST /funeralvaluables

BarryStevens

OK, thanks