4 ms·
I never had any uncertainty regarding where I can use a given entity id in a well designed API. Fix the naming and organization of your API if that's a problem
by raquo 7y ago
I never had any uncertainty regarding where I can use a given entity id in a well designed API. Fix the naming and organization of your API if that's a problem for your users.
Conversely, I often need to log or store API-provided entity ids on my side, and having to parse it out of a URL or store irrelevant URL bytes in my own database would be really annoying.
You're not going to avoid the need to compile entity URLs on the client side either, unless you only make requests to entities returned by the API, which would be a weird constraint to design client code around.
I really don't see the point to any of this.
- underwater 7y agoI would never feel comfortable `fetch`-ing the URI provided by the API without validation. That sounds like a security issue waiting to happen.
- fagnerbrack 7y agoThe browser already does it with the anchor tag and the user decides to navigate or not, the difference in an API is that it's a machine driving. What's the security issue you're talking about?
- cyphar 7y agoSSRF is the most obvious (potential) issue.
- pmontra 7y agoDoes an API returning only relative URLs address your concern? The validation would be intrinsic in the client side concatenation of the server address with the relative URI.
- twblalock 7y agoIf you save the relative URL in your database and then the API changes its URL schema, you will need to migrate everything you stored to the new schema. If all you stored was the ID, all you would need to change is the logic in your API client which accepts the ID and constructs the URL for it.
- chii 7y agoa change that necessitate a URL schema change would be just as far reaching had the system been designed with using IDs. For example, if the entity ID changes from being an integer, to being a GUID, you'd still have to write code to update your schema (presumably, from an int column to a GUID/string column).
- raquo 7y ago(Not the GP) Yes, when done right, but it's iffy. For example, the article includes URLs like "/people/123". The security of having a leading slash in these depends on API base URL. "https://api.hotstartup.com/v1" https://api.hotstartup.com/v1" – safe "https://api.hotstartup.com" https://api.hotstartup.com" – unsafe with ".evil.com/people/123" I wouldn't really call this particular scenario a security issue, but allowing such things is a bad habit that will eventually bite. It's like not HTML-encoding values like usernames that you "know" are safe (but you know are not HTML-encoded).
- nertzy 7y agoYes, this is why developers should use URI-building libraries instead of direct string manipulation to modify URIs. If I visit an HTML page with a link to “.evil.com/people/123” and click on it, the user agent won’t append “.evil.com” to the hostname. You’d instead get something like “https://api.hotstartup.com/.evil.com/people/123” https://api.hotstartup.com/.evil.com/people/123” which would be safe (if not broken).
- jbverschoor 7y agoA lot of environments have whitelisted outgoing connections.
- jeltz 7y agoAnd a lot of them don't.
- deleted 7y ago[deleted]
- mpnally 7y agoYou don't have to parse entity IDs our of URLs — the URL already is an entity ID, and from the client's perspecitive, it doesn't have any sub-parts that can be parsed out, except those defined in the URI spec (scheme, authority)
- raquo 7y agoThat only works if fetching the /people/123 URL is the only thing you will ever do. If you need the real 123 entity id in any other context, e.g. to display it to the user, or to make a user-accessible website link to that entity (e.g. "view this transaction in stripe dashboard"), you'll need parsing. I also mentioned that I don't want to store redundant garbage in my logs and database, especially if I want to index the column containing that entity id.