It's important to separate the two different concerns raised by your question. The first, the one you are directly asking about, is what identifier to use in your URLs. The second concern is the design of your database. Since this is the Database forum I'll answer the second of these first, just as other people already have done.
In database design it is quite common for things to have multiple identifiers. In a relational database table the identifiers are keys and there's nothing wrong with having several different keys in a table. It is quite common for a table to have keys both for the business key (the identifier familiar to end users) as well as a "technical" or "surrogate" key (a key seen and used by database developers and DBAs but without business meaning and not exposed to the end users).
So although the points made by wwb_99 and DaveMaxwell are potentially relevant concerns when implementing keys, none of those things in themselves should stop you using any appropriate key value in your URLs - because there is no reason why you have to choose only one type of key or the other. Interface design should not dictate database design.
The most important criteria for choosing keys are Familiarity, Stability and Simplicity. A user-visible product code, stock number or possibly even a unique product name are good candidates for keys but in all cases business requirements should be the deciding factor. For instance, stability is desirable from the database designer's point of view but doesn't necessarily match what is really required from the user's point of view since key values sometimes need to change.
What I suggest you do not do is expose any surrogate key in the URL. That would undermine some of the advantages of having a surrogate key in the first place. Of course, once you expose the key to users it inevitably acquires some business meaning and is no longer a surrogate.
Hope this helps.