Question

We received a request to create a REST api. I was a little confused in the example of provided by our client. As you can see below, they’ve identified the app_id and secret in the URL before the @. The remainder of the URI looks like what I would expect.

Is this valid? I thought maybe this is some weird cURL format I haven’t seen before.

https://{application_id}:{api_secret}@api.example.com/entity/{entity_id}/ 
https://{application_id}:{api_secret}@api.example.com/entity/{entity_id}/entity_locations/{locations_id}/

Just seeing if anyone has seen this format before?

Answer 1

A URI is made up of various parts, one of them being the authority part, which can feature optional username:password element.

The full scheme is:

scheme://username:password@domain:port/path?query_string#fragment_id

This way your REST api remains stateless [not relying on previous app states like storing stuff in session]. But I advice you not to explicitly go with the username:password@stuff route, but to rely on Basic HTTP Auth, so the credentials are sent encoded in Base64 at least.

---

EDIT: a brief note about BasicAuth now you’re asking – things go like this:

• you make a request to http://johndoe:12345@service/api/foo/bar;
• are credentials good? Ok, you get a 200 OK response with proper body;
• are they not? You get a 401 Unauthorized response.

In the latter case, it’s the browser [or any other program / script performing the request] that should prompt the user with the login popup.

Usually browsers ask you to cache credentials not to ask them every time, but this does not mean that they are not sent – it’s just that every request to protected resources are featured with such header:

Authorization Basic base64encode(username:password)

Where base64encode is your custom way to encode the username:password string.