Simple question, in terms of best practice is it better to format my URL like this:
http://www.example.com/search?query=hello&page=1
or like this:
http://www.example.com/search/hello/page/1
Can you provide a valid reason for your choice please.
First one fits the situation where you want to "filter" your result if it gets a little too complicated, like this example:
cars.com/audi/sedan/a/4/black/manual.....
this is gonna take so long and complicated and result will be nightmare, but this would work better:
cars.com/mercedes/amg?color=white&transmission=manual
2nd way is just like thinking it of a 'folder'ed structure:
socialmedia.com/shares/1/comments/1/page/2
I am pretty sure you get the idea.
p.s. if you will provide your API to a brand new clients, who don't know anything about it, then first one is also more understandable but, i suggest you also have a API documentation which describes the parameters and the relevant poasible other calls as well. in this way your url formatting will be clearer and clients will not struggle to solve parameters in the url.
The first way is not only functional, but lets a human understand what the name/value pairs are. Sure you could go into configuration and string manipulation and make your URL look like the second example and still function, but from a readability pov and ease of function, the first one is best.
Related
I'm continuing my experiments with falcor and enjoying most of it, but I'm noticing something concerning.
I'm assembling my JSONGraph from multiple disparate APIs, exactly what falcor-router is intended to do. However I can't seem to find a way to cleanly provide a catch-all for fields that don't need special handling w/o blowing up any routes that do need to do special handling.
My routes look something like the following:
items[{integers:ids}].name
items[{integers:ids}][{keys:fields}]
No matter the order I declare the routes in the generic one always wins. Is there a better way to avoid this than the full-nuclear option of structuring my routes like this?
items[{integers:ids}].name
items[{integers:ids}]['fooga', 'wooga', 'booga', 'tooga', ... ]
That seems very brittle, if the data coming from the backing server changes I have to update not only my application code but my router as well. It also becomes a real mess if you have deeply nested objects as the number of permutations climb in a hurry.
I believe this is a bug. The router should match the most specific path first. I would appreciate if you could log it as an issue. We will fix it for you.
There is a webpage parser, which takes a page contains several tags, in a certain structure, where divs are badly nested. I need to extract a certain div element, and copy it and all its content to a new html file.
Since I am new to lua, I may need basic clarification for things might seem simple.
Thanks,
The ease of extraction of data is going to largely depend on the page itself. If the page uses the exact same tag information throughout its entirety, it'll be much more difficult to extract than it would if it has named tags.
If you're able to find a version of the page that returns json format, then you're that much better off. Here's a snippet of code on something I wrote to grab definitions from a webpage that did not have json format:
local actualword, definition = string.match(wayup,"<html.-<td class='word'>%c(.-)%c</td>.-<div class=\"definition\">(.-)</div>")
Essentially, this code searched down the page until it found the class "word", and took the word after it (%c is the pattern for control characters). It continued on to "definition" and captured that, as well.
As you can see, it's a bit convoluted, but I had the luck of having specifically named tags for what I wanted.
This is edited to fit your comment. As a side note that I should have mentioned before, if you're familiar with regular expressions, you can use its model to capture what you need. In this case, it's capturing the string in its totality:
local data = string.match(page, "(<div id=\"aa\"><div>.-</div>.-</div>)")
It's rarely the fault of the language, but rather the webpage itself, that makes it hard to data mine anything. Since webpages could literally have hundreds of lines of code, it's hard to pinpoint exactly what you want without coming across garbage information. It's why I prefer a simplified result such as json, since Lua has a json module that can encode/decode and you can get your precise information.
I have the following call:
http://localhost:3000/arc/v1/api/menus/51/only_items_with_notes
and I'm curious what is the preferred structure of the url - This reads fine and is totally clear what it means. But I am not sure if this is the canonical way to do this. One issue is that it does proliferate the routes.rb file. I have:
get '/menus/:menu_id/only_items_with_notes' => 'api_menus#only_items_with_notes'
One think I don't like is that it reads a bit like a pseudo nested attribute. What is the proper, canonical way to do this?
That’s pretty deep nesting. What other routes do you have?
In the absence of more information, I’d suggest that only_items_with_notes is really a filter on the functionality of the index action. You can use a query parameter to restrict the items to those with notes.
I have a question.
I have comment model, in which it has body column that users can type anything in there.
obviously user might type the url link to other website.
In my guess, I think it should be replaced with < a href > tag when it is being saved.
Is there any good gem or something to handle this kind of thing?
If you don't want to use a full-blown markdown parser (Redcarpet), use Rinku. It's super fast and safe. Do not use any regex based solutions as you would most likely open yourself to security risks.
text = "Hello! Check this out: https://github.com/vmg/rinku"
Rinku.auto_link(text, mode=:all, link_attr=nil, skip_tags=nil)
Produces:
=> "Hello! Check this out: https://github.com/vmg/rinku"
Preserving for posterity's sake, but I feel it's important to note that this is NOT a secure way to solve the problem. Unless you want to figure out all the security implications for yourself, don't follow this advice. Jiří Pospíšil's answer is better. =D
You don't really need a gem to do that (I personally try to avoid gems for something so simple). Write a regular expression that is reasonably reliable for your purposes, and then use something like
input.gsub(regex, 'some text')
to convert the links into their html equivalent. Note that you'll need to use raw to display the results of this, otherwise rails will escape the output for you. This also means users will be able to put other arbitrary markup in, unless you escape it as it goes into the database. Make sure you do that.
Alternately, you could do the same thing as you display it, with slightly different considerations/steps necessary.
I know with symfony2 is very trivial get pretty urls through routing system and I love it. But when the routes parameters are based only in slugs I've got to find by slug.
$em->getRepository('Bundle:Entity')->findOneBySlug($slug);
I thinking about combine both parameters like stackoverflow http://mysite.com/articles/234/the-title. Mantaining the slug parameter only for SEO proposes and find directly with the entity id (234).
$em->getRepository('Bundle:Entity')->find($id);
What are the pro / cons using this strategy. I'm right way?
I would go as you suggested and use both an unique identifier and a slug, because you do not have to worry about unique slugs this way.
But one thing you should is check if the slug is valid.
So do not use URLs like this: /articles/{id}/{unchecked-slug}, because if you do that you can reach the same article with an unlimited number of different/evil URLs, i.e. /articles/123/the-correct-title and /artcle/123/some-dirty-words.
So i would suggest using something like this:
$em->getRepository('Bundle:Entity')->findOneBy(array('slug' => $slug, 'id' => $id);
I am not a SEO expert, but I do not think, that shorter URLs are THAT important, as long as it contains useful words, that may be part of a search.
From a pure SEO perspective, you want to have a shorter URL since they tend to attract more clicks and are easier to share. However, catering to only SEO would be a mistake IMHO.
Adding a unique identifier to the string would be a smart thing to do, and would make things easier to lookup and maintain. I would suggest putting the unique identifier at the end of the URL string to maximize the "SEO effect".
Keywords in the URL might be a ranking signal, but really they drive up the CTR if the keywords found in the URL match the user's query. When that happens, the keywords in the URL become bolded in the Search Results Page (SERP). By putting the ID at the end of the URL, you're helping to ensure that the keywords in the slug have a better chance of appearing to the user, which means a better chance of being bolded, which hopefully leads to more CTR.
Here's what I would suggest:
http://example.com/articles/the-title-234
No one has suggested it so far, so I'll offer what WordPress does. If there is already a permalink in the database that is identical to the one being supplied, you simply concatenate a counter at the end.
http://example.com/blog/my-article
becomes
http://example.com/blog/my-article-2
becomes
http://example.com/blog/my-article-3
The method eywu suggested is second best, but only because you still have the full ID in the permalink. No one wants to remember that, and it has no meaning to search engines.