Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escape identifiers #41

Open
tmaier opened this issue Jun 17, 2014 · 1 comment
Open

Escape identifiers #41

tmaier opened this issue Jun 17, 2014 · 1 comment

Comments

@tmaier
Copy link
Member

tmaier commented Jun 17, 2014

According to https://github.com/interagent/http-api-design#support-non-id-dereferencing-for-convenience we can provide non-id identifiers for convenience.

This could be essentially everything.
I could for example query for a standard, say /standards/ISO 9000:2005 (/standards/ISO%209000:2005)

I propose to run URI.escape on every identifier passed to the api.

@schneems
Copy link
Collaborator

schneems commented Aug 27, 2020

That link no longer works, here's a good one that is locked to a commit:
https://github.com/interagent/http-api-design/blob/193f6eeee57d69121af82e74cce457ad8f03e5b4/en/requests/support-non-id-dereferencing-for-convenience.md

Here's the entire contents:

#### Support non-id dereferencing for convenience

In some cases it may be inconvenient for end-users to provide IDs to
identify a resource. For example, a user may think in terms of a Heroku
app name, but that app may be identified by a UUID. In these cases you
may want to accept both an id or name, e.g.:

```bash
$ curl https://service.com/apps/{app_id_or_name}
$ curl https://service.com/apps/97addcf0-c182
$ curl https://service.com/apps/www-prod
```

Do not accept only names to the exclusion of IDs.

I view this statement as a bug report

I could for example query for a standard, say /standards/ISO 9000:2005 (/standards/ISO%209000:2005)

If an ID or artifact has non-valid url parts it makes sense that this library could handle escaping them. My worry here is if anyone is abusing the existing behavior to force something like this:

$ curl https://service.com/apps/{www-prod/dynos/web}

Even though this might not be "supported" or "valid" use, it might accidentally be used that way and uri escaping would be backward incompatible. I would want to ask how we could detect on such cases and warn or provide some sort of a stable opt-out interface etc.

Follow up question: Is there a way to quickly generate and show URLs are or are-not-uri-escaped currently? This issue is very old and I'm assuming the behavior you're describing still exists but I currently don't have a way to verify it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants