Backend engineers, how do you mindlessly design some SHI-like URIs to disgust the mobile/front-end engineers? Hope this article can give you some enlightenment. Method one: make some do not know so-called name. For example: api.example.com/68dd0-a9d3-… Don’t do the readable: 58.com/bj/ershou/3… Voice-over: Beijing/Second-hand channel/post ID_
Method two: make more foreign languages, preferably the kind that is easy to spell wrong. For example: api.exapmle.com/louvre/da-v…
Voice-over: The Louvre/Da Vinci/Mona Lisa
Method 3: add more “/” at the end of THE URI, let others think it is a directory, but also may help them to make a 301 jump, the performance is bad.
For example: api.canvas.com/shapes/
And such unambiguous API, is absolutely not: api.canvas.com/shapes
Method 4: Use “More”“Instead of” – “improves misreading of URIs and tries to mask the underlining effect in the text viewer.”“.
For example: api.example.com/blogs/my_fi…
How about that, with the scribing and scribing? And this is more relaxed, is not recommended: api.example.com/blogs/my-fi…
Method five: use more capital letters to confuse the caller and embarrass the caller.
Such as:
Api.example.com/My-Folder/M…
Voiceover: URI is case sensitive in RFC 3986.
Got it? Take care to protect yourself! All jokes aside, a good URI should be: (1) RESTful is the basic principle, and the name should make sense; (2) Don’t use foreign languages that are easily misspelled; (3) Do not add a slash at the end of the URI; (4) Use “-” instead of “_” to improve URI readability; (5) The use of capital letters is prohibited;
The architect’s path– Share technical ideas
Research: What weird URIs have you seen?