Entry_Point URI's

AusMarkB

I have updated the HREFNames and HREFURIs variables in the entry_point services but I can't seem to get them to return.

My limited understanding is that they would be the response if the remainingurl variable is null. In other words you haven't called anything further.

So this
http://mywebpage/api/contacts would and does go through entry_point to http_contacts_services because the remaining url is 'contacts'

that leads me to assume (obviously incorrectly) that
http://mywebpage/api would have a null remainingurl and therefore return my list of services.

However when I do that, I don't even reach entry_point and I do receive a 404 Not Found error.
In fact I don't even get to MCP nor even give the socketserver a nudge.

Any pointers?

AusMarkB

I've added 'services' to the entry_point case statement so now
http://mywebpage/api/services achieves the end goal.

I'd still welcome any suggestions as to help my understanding.

Thanks.

DonBakke

Mark,

I might need to see more of your code for me to better understand what you are experiencing. You are welcome to email it to support@srpcs.com if you are not comfortable posting it here.

that leads me to assume (obviously incorrectly) that
http://mywebpage/api would have a null remainingurl and therefore return my list of services.

This was a point that Barry was trying to make in a recent discussion thread. He was pointing out that there could be up to three different places in the code where the list of services needs to be identified (and, as a way of simplifying this, he stores these in a configuration record and then Xlates them into his code).

However, the real issue is this: no service that can "pass through" to other services will automatically return the list of services when it is just an end point. You always have to make sure you return this as a response.

Here is one reason why this simply isn't done automatically: authorization. While a given user might be authenticated into the API, that doesn't meant the user is authorized to use every service. Therefore, the developer must always assume the responsibility of building the response that returns the list of services that the current user is authorized for.

Now, if your API does not need to authorize a service (i.e., authentication alone is sufficient), then you can certainly do what Barry did and streamline this. The SRP HTTP Framework did not want to assume anything and thus over-simplify the tool.

However when I do that, I don't even reach entry_point and I do receive a 404 Not Found error.
In fact I don't even get to MCP nor even give the socketserver a nudge.

Do you get any content with this 404 error? For instance, does it appear that the web server is producing this or the API?

AusMarkB

Don,

This was just a case of me still exploring the sample code.

The beginning of the case statement for the entry_point service is

Begin Case Case RemainingURL _EQC '' // There is no remaining URL, which means this is the end point. SelfURL = HTTP_Services('GetSelfURL') Begin Case Case HTTPMethod _EQC 'GET' ; GoSub Get Case HTTPMethod _EQC 'OPTIONS' ; GoSub Options Case Otherwise$ ; ValidMethod = False$ End Case

Out of the box the 'Gosub Get' creates the response that lists the services except in my case at least, if this condition is true (ie RemainingURL _EQC "") then I don't actually reach this routine to trigger it.

By adding the condition

Case (NextSegment _EQC 'services') and (HTTPMethod _EQC 'GET') GoSub Get

... I get there and Voila.

Do you get any content with this 404 error? For instance, does it appear that the web server is producing this or the API?

It would be the web server returning the error because OI isn't even nudged. Based on this content in the error

Requested URL http://localhost:80/api
Physical Path C:\inetpub\wwwroot\api

The Physical Path should be "D:\pf\edmen94http" so I suspect the issue lies with my rewrite rule or something though I don't know why.

So I guess there's two questions.

1. Any thoughts on why the rewrite rule wouldn't look elsewhere at the root level?
   
2. Is the sample code supposed to work, ie should you be able to reach the entry_point service as an end point?
   

That last question is not a philosophical/ authorisation one, just a "am I understanding what I'm seeing one"

DonBakke

Mark,

I'll respond in reverse order.

Yes, the sample code is supposed to work "out of the box". The only reason some of the services might not work would be if you were missing the OpenInsight tables that the users and contacts services assume are present. However, even if that were the case, those services would still get executed, but the response would be some kind of an API error.

I'm not the resident expert with the rewrite rules. Jared helped figure out all of them for IIS, Apache, and Abyss. They are all based on regular expressions, which is a skill to master unto itself. Hopefully Jared will catch this thread and respond. However, he might want to see your rewrite rules to offer any suggestions.

I do think your suspicions are right. The rewrite rules are preventing the web server from properly calling your path with OECGI. How are you getting your machine to recognize the http://mywebpage URL? Did you create an entry in the HOSTS file? Is that the actual URL home or is that just for example purposes?

AusMarkB

Just for example purposes

Here's the url rewrite

BarryStevens

Mark,

Try api/* in 'Pattern'
Using:
Wildcards

AusMarkB

Thanks Barry.

Adding the asterisk yet leaving the Wildcards as Regular Expressions worked in the rewrite url test space.
Unfortunately Postman didn't catch on and still returned the 404.

Must be closer though.

DonBakke

Mark,

From what I can tell, you are using the same rewrite rules as documented in our blog article. The only difference is you are using /api versus /app, which is perfectly fine.

I am not sure if this is relevant to the IIS or Apache rules, but in Abyss we have two rules: one for the /api and one for the /api/additional url.

JaredBratu

Mark,

The screen shot you posted shows the rewrite rule with an extra forward slash / in the brackets. The rewrite rule should be:

^app/([_0-9a-z-]+)$

Don is correct, to get http://mywebpage/api working an additional rule is needed. The rules from the blog article were designed to hide OECGI and since OECGI isn't normally called without arguments the rule doesn't work.

Please add a rule like this:



Please make sure it comes after the catch-all rule you already have. The order should appear like this:



Please substitute 'app' for 'api' in the rules since you indicated your preference to use 'api' instead of 'app'.

AusMarkB

Thanks Jared.

I'll keep the additional rule in mind if I decide I need it.

So far as the additional slash, that was intentional as per this post.

FWIW, in the rewrite rule I also had to add a '/' within the brackets within the Pattern.
If I didn't and my url went any longer than a single segment, then the rewrite just rewrote it to a default value on 'C:' drive and oecgi was never even nudged.

In other words, I changed the pattern from "^api/([_0-9a-z-]+)$" to "^api/([_0-9a-z-/]+)$"

Otherwise http://localhost/api/whatdidwhosay would be correctly redirected to the physical path
D:\pf\edmen94http\OECGI4.exe\whatdidwhosay

but http://localhost/api/whatdidwhosay/fox would be incorrectly redirected to

C:\inetpub\wwwroot\api\whatdidwhosay\fox

when I really want

D:\pf\edmen94http\OECGI4.exe\whatdidwhosay\fox

If you've a better suggestion for tackling that problem, I'm all ears.

JaredBratu

You are correct, the extra slash is required otherwise IIS skips the rewrite rule because it doesn't match '/api/whatdidwhosay/fox' and instead looks for a matching directory on the file system. We will have to update the rewrite rules for IIS as it's slightly different than the rules in the blog article about hiding OECGI.

AusMarkB

Thanks for the clarification Jared. I never said I knew why, just that it seemed to resolve a symptom. :)

Happy birthday for the other day too.