I have been inspecting a variety of websites recently and keep encountering URLs containing strings like this, sometimes capitalised, sometimes not:
c8e700e6-4166-11e7-82b6-896b95f30f58
Does anyone know the significance or origin of this? Is it an encoding schema, something to do with the webapp framework, or something else?
Thanks
In technical terms, it's called a UUID or a universally unique identifier (aka GUID). The purpose is almost always to ensure that the page loaded by the browser is a unique URL and therefore not cached, but it can also be used to uniquely identify a session with the server.
It's not usually considered to be best practice to do it this way.
This is a GUID, use for better future unity.
Remove the possibilities of conflict on database of two companies.
PS:Sorry for my English.
Related
I am working on an application that will provide information for certain events, and am wondering what the best way to structure my URI resources is.
The easiest way is to simply use an ID for each event; such as;
Baseurl/Events/{EventId}
The issue with this is that the ID is obviously not something that will be known to the customer. I would prefer to have something more like;
Baseurl/Events/{EventName}
Perhaps a more important reason for doing this is for SEO purposes. If I am targeting a keyword for the event, surely it would be more beneficial to have the event name in the URL?
My issue with using the event name is that obviously it’s not as ‘parseable’ as an ID, in that it becomes sensitive to event name changes etc. Also adding spaces into the URI means that customers aren’t likely explore by typing resource names in, and again could lead to parsing issues.
What is the standard practice in this area? Is using an ID the norm, or using a resource name? If I take Wordpress as an example, I know that the postname can act as the resource identifier, so I know at least one instance of the name being used.
Go for the hybrid approach, much like how StackOverflow is built: use the ID in the URL for your internal usage and append the name afterwards for readability and SEO.
I have some SSRS 2008 reports that need to be localized. That is:
Report titles, column headers, etc. all need to be in the user's locale. (Note that in my situation, the User!Language expression may or may not be useful, but that's not the major problem.)
The localized strings must be retrievable from a table within the same DB as the actual report data. Separate localized RDLs won't work for us. Localization will be managed by non-developers, so we've provided a UI for them to change localized strings themselves.
We'd very much prefer not to retrieve strings through a custom assembly, if we can help it. We've had trouble in the past deploying custom assemblies, and of course it introduces some debugging complexity as well.
All ideas are welcome.
I guess you just need a table on the db with everyone's country preference against their user ID. Then based on the user ID you can set the formatting accordingly.
Pretty bad practice though. Why can't you use User!Language?
i keep hearing that i shouldn't be using primary keys in my asp.net mvc url
for example: /Users/Edit/1243
what is the issue here?
what is the alternative, putting in user names? as you want it to be unique, it seems like primary key is the cleanest option
thoughts?
I don't see any problem with putting the primary key on the URL (neither do the creators of Stack Overflow and countless other sites either for that matter). One thing that is often done is to supply the primary key and also supply a SEO and user friendly "slug" that is a human-readable title of the data that the identifier links to.
If you intend to identify a resource (in your case, a user account) you will have to supply a unique identifier on the URL. Even if you decide to not use the primary key you must still choose an identifier that cannot change.
One of the issues with putting (numeric) primary keys in the URL is someone (or some search engine) could start replacing the number with other numbers to see what you've got in your db. Often this isn't a problem, but if...
you have a situation where users are only supposed to edit or see their own data
you have content in your db that you are "hiding" by not linking to it on your website
etc...
...you have to make sure you do permission checking in your Action method to ensure no one sees data they shouldn't. As long as you are doing the proper permission checking on each request - primary keys shouldn't pose a problem.
There could be two reasons
- Security consern
- SEO Optimization
putting usernames seems to be a good alternative
I think you should keep that primary key - otherwise how will you identify your entity.
Two points:
SEO - it's better for Google & Co to read text. Why not put ID + name in the URL
Security: But it is a must to check in your BL if the current user has access rights to the requested entity.
There's no real issue with using the primary key, especially if it's int (guids make for ugly urls).
An edit is a bad example, what if you had something like
www.example.org/users/1234
That doesn't really tell you much. and if it's a profile page it's awfully counter-intuitive.
The right URL for the right job.
I'm designing a hosted software-as-a-service application that's like a highly specialized version of 37Signal's Highrise product. In that context, where SEO is a non-issue, is it worth implementing "pretty URLs" instead of going with numeric IDs (e.g. customers/john-smith instead of customers/1234)? I notice that a lot of web applications don't bother with them unless they provide a real value (e.g. e-commerce apps, blogs - things that need SEO to be found via search engines)
Depends on how often URLs are transmitted verbally by its users. People tend to find it relatively difficult to pronounce something like
http://www.domain.com/?id=4535&f=234&r=s%39fu__
and like
http://www.domain.com/john-doe
much better ;)
In addition to readability, another thing to keep in mind is that by exposing an auto-incrementing numeric key you also allow someone to guess the URLs for other resources and could give away certain details about your data. For instance, if someone signs up for your app and sees that their account is at /customer/12, it may effect their confidence in your application knowing that you only have 11 other customers. This wouldn't be an issue if they had a url of /customer/some-company.
It's always worth it if you just have the time to do it right.
Friendly-urls look a lot nicer and they give a better idea where the link will lead. This is useful if the link is shared eg. via instant message.
If you're searching for a specific page from browser history, human readable url helps.
Friendly url is a lot easier to remember (useful in some cases).
Like said earlier, it is also a lot easier to communicate verbally (needed more often than you'd think).
It hides unnecessary technical details from the user. In one case where user id was visible in the url, several users asked why their user id is higher than total amount of users. No damage done, but why have a confused user if you can avoid it.
I sure am a lot more likely to click on a link when I mouseover it, and it has http://www.example.com/something-i-am-interested-in.html.
Rather than seeing http://www.example.com/23847ozjo8uflidsa.asp.
It's quite annoying clicking links on MSDN because I never know what to expect I will get.
When I create applications I try my best to hide its structure from prying eyes - while it's subjective on how much "SEO" you get out of it - Pretty URLs tend to help people navigate and understand where they are while protecting your code from possible injections.
I notice you're using Rails app - so you probably wouldn't have a huge query string like in ASP, PHP, or those other languages - but in my opinion the added cleanliness and overall appearance is a plus for customer interaction. When sharing links it's nicer for customers to be able to copy the url: customer/john_doe than have to hunt for a "link me" or a random /customer/
Marco
I typically go with a combination -- keeping the ease of using Rails RESTful routing while still providing some extended information in URLs.
My app URLs look something like this:
http://example.com/discussions/123-is-it-worth-using-pretty-urls/
http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments
http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments/34567
You don't have to add ANY custom routes to pull this off, you just need to add the following method to your model:
def to_param
[ id, permalink ].join("-")
end
And ensure any find calling params[:id] in your controller is converted to an integer by setting params[:id].to_i.
Just a note, you'll need to set a permalink attribute when your record is saved...
If your application is restful, the URLs that rails gives you are SEO-friendly by default.
In your example, customers/1234 will probably return something like
<h1>Customer</h1>
<p><strong>Name:</strong> John Smith</p>
etc etc
Any current SEO spider will be smart enough to parse the destination page and extract that "John Smith" from there anyway.
So, in that sense, customers/1234 is already a "nice" URL (as opposed to other systems, in which you would have something like resource/123123/1234 for customer 1234 resource/23232/321 for client 321).
Now, if you want your users to be regularly using urls (like in delicious, etc) you might want to start using logins and readable fields instead of ids.
But for SEO, ids are just fine.
Well, my question is simple.
Does the ID affect the position of a webpage on Google ?
I have links like this
http://example.com/news/title-slug/15/
and people say to me that I should remove the ID from the URL.
And I belive that is not true. By my logic, you can't depend on the title's slug. I know it should work perfectly fine if there aren't two pages that have the same title, but why should I remove the ID if there is no harm when it's there.
Yes, leave it there.
Google has no business trying to second-guess what each element of a URL represents and changing its index based on that.
URLs by their nature can map to any resource, and I'm pretty sure Google recognises that. All you should do is ensure that multiple URLs don't have the same content by using redirects. So, for example, http://example.com/news/wrong-title-slug/15/ should redirect back to http://example.com/news/title-slug/15/ rather than just echo back the same page. Google doesn't really like duplicate content.
It's fine.
But I would not put that behind the title-slug though. Some url might get more confusing than the others.
http://example.com/entry/how-to-solve-question-45/15
a better one would be :
http://example.com/entry/15/how-to-solve-question-45
Besides, you can't really rely on just the title-slug, because changing the title of an entry means breaking user's bookmark. Not to mention that it is faster to retrieve an entry from the database by an integer ID instead of an url-slug.
The problem here is not whether Google will accept it, but whether or not doing so is user-friendly.
A common reason for keeping the ID in a URL is to ensure that the URL is unique. For example, if two people on here were to create a question named "Jon Skeet Facts" we'd have a problem, whereas with the ID the users are aware that they are two different questions with the same title. This is the same as with relational databases where a unique identifier is required.
In essence, why care what Google thinks? The whole Search Engine Optimisation industry is a farce, and this is coming from someone who has been paid more than once as a SEO Consultant. Why follow what Google wants when you can map Google's intentions by making your website perfect for the user? If you make a good website Google will reward you. The ID has a reason to be there, so keep it in.
I think your fine leaving it in. Seems to make sense as you get the element for identification and the element for being descriptive. It is done on here after all.
Zeus won't strike you down for it. I prefer not to have meaningless numbers in there because it's not very attractive or semantic.
Having the id will NOT hurt your SEO rankings. Having the slug there ensures that the page's main keywords will be indexed so it's all good.