You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#### 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:
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.
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.The text was updated successfully, but these errors were encountered: