I am trying to separte the domain name from url. But I am confused if i should consider it domain name or not.
http://en.wikipedia.org/
is it considered a domain name with or URL ?
You posted the URL http://en.wikipedia.org/ which contains the domain name en.wikipedia.org.
A FQDN is a DNS identifier consisting of hostname and domain, like this one:
en.wikipedia.org.
A HTTP URL however, also provides among other things a scheme (the protocol in your case) and a path, which is simply / (the mandatory beginning) in your case:
http://en.wikipedia.org/
What do you mean by “separate”? Were you curious about the abstract concept, or do you want to actually separate the strings respectively?
Related
We have a property that uses the obsolete Umbraco.ContentPickerAlias
On our development sites, that are also multiple site (each site has a URL set in the Cultures and Hostnames), the property returns a relative URL (eg: /home/) but on our test sites, the property is returning a full URL (eg: https://site1.com/home/)
We have code that assumes the URL will be relative (which I will remedy)
Is there a setting on the site/umbracoSettings.config that is causing this property behaviour?
This issue was not related to the property itself, but that if a site has a domain in the Cultures and Hostnames that is not equal to the domain itself, each page's link will be absolute rather than relative. The ContentPicker is merely returning the value for the chosen element's link
I'm using the elasticsearch plugin and I'm running searches using elasticSearchService.search(myKeywords) which searches for keywords over all the domain classes marked as searchable.
Now I want to restrict the search to two specif domain classes. I can see there are options named indices and types that can be passed to the search method, but if I simply use my domain class names on them I get errors telling the index or type doesn't exist. What exactly should I do to achieve what I want?
(I'm new to lucene and elasticsearch and I'm not sure I understood the index and type concepts. Reading the docs I could only find examples to restrict searches to an specific field, not a hole domain class or whatever it is mapped to, in lucene/elasticsearch concepts).
The way to go is:
elasticSearchService.search(myKeywords, [types:["myPackage.MyClass","myPackage.MyOtherClass"]])
The results are as expected, but I'm still worried about having one index (and one type) per domain. Not what I expected but I can't see how to map all domain classes to a single index for the hole database as stated by the docs
I'd like to be able to have a way of pulling in a URL prefix from a properties file or the like for references to static resources in Thymeleaf, so that I can, e.g., have a file url for development and a reference to, e.g., static.cdn.com Having a variable added to every page's context is too much repetition. Is there some approach short of creating a dialect so that I can have a configurable attribute?
I saw this in Grails documentation
static mappings = {
"/$blog/$year/$month/$day/$id"(controller: "blog", action: "show")
}
The above mapping would let you do things like:
/graemerocher/2007/01/10/my_funky_blog_entry
The individual tokens in the URL would again be mapped into the params object with values available for year, month, day, id and so on.
I have doubt is, if i have one more mapping just different is /$day/&month( above /$month/$day ). Even same path is valid for my new mapping also, then how it identifies which dynamic mapping and how to bind to params object.
You should never define 2 mappings like this:
"/$day/$month"(controller: 'one', action: 'index')
"/$month/$day"(controller: 'two', action: 'index')
A problem with that is that there is no way to ever distinguish between them for forward URL mappings. If a request comes into something like /5/6, there is no good way for the framework to decide which one to use. You could use named mappings which helps with reverse URL lookups, but the forward mappings would still be a problem. You need something that makes them unique in order for them to make sense. They could have a different prefix, or constraints but it doesn't make sense to have 2 separate mappings like those I described above. There is no way for the framework to make sense of those.
if there is no clear single mapping (e.g. overlap) the mapping, which is most specific, wins (least wildcards, most static parts). at last the order in your urlmappings decides.
pre-edit (see comments, wrong example):
see https://github.com/grails/grails-core/blob/master/grails-web-url-mappings/src/test/groovy/org/codehaus/groovy/grails/web/mapping/OverlappingUrlMappingsMatchingSpec.groovy
I understand that in MVC pattern and in REST services it is common to use URIs like /items/{id} but what is bad thing about using query parameters in the URI?
GET /items/{id} vs GET /items?id={id}
Further, lets say an entity has 'referenceId' field that points to some related (say parent) entity, and I need to create REST service to get all items for parent entity, which way is better:
GET(POST) /items/parent/{parentId}
or
GET(POST) /items?parent={parentId}
Will be grateful for insights that would help to resolve my subjective issues on constructing URLs for REST services.
I would use the following schemes.
/items/id
This uniquely addresses a resource of items with id id. We are not using parameters as a parameter to uniquely address this resource (as is the case with the other option). Just as
miguelcobain suggests.
/parent/id/items
Here id is an id to uniquely address a resource of parent and from those we collect/retrieve the items it references. From what you have said in the question it seems that parent references multiple items, like a container or collection.
The convention I use for this is to narrow down the scope going from left to right. Therefore in case items could be active or inactive. Thusly items have a property or attribute to be active or inactive. Narrowing down on this I get the following scheme:
/items/active
/parent/id/active
For your first question:
/items/{id} should retrieve a single resource with the specified id or 404 if it doesn't exist.
/items/?id={id} should retrieve an array (even if only one in the array) because you are querying the collection.
For your second question:
I agree with #miguelcobain's assessment - if the item is a specific resource/entity, just use the proper resource path to retrieve it.
To make this easier on the consumer, create a link header with rel="parent" and/or include the uri in the child resource. For an example of link headers, see GitHub's pagination api.
Of course, REST principles don't care about aesthetic details on URLs. It just imposes that every resource should be uniquely addressable.
Furthermore, using the query parameters to uniquely address something "kind of" violates the semantics of a "parameter", doesn't it? A parameter should be something optional, something additional and parameterized. Something like a detailed search on a collection of items, for example.
What you wrote may make sense in some cases. It depends.
In your example, is the item really a resource? If not, you could just do GET(POST) /parents/{parentId}.
If parent is, say, a boolean, and you want to search the items that have parent equals to true, then using the parameters makes sense. But since you're explicitly saying that you want a parent with a specific id, I assume that parent is a resource itself and I would uniquely address that resource using your option 1.
I hope I made myself clear.
It seems to me there are no rules to follow.
items/{id} - this convention is suitable for GET item by given id. If user doesn't provide id then it returns 404 status code.
items/id={id}&name={name} - this type of convention is suitable for search multiple items by given criteria. If no items are found, it is not a 404 situation, you simply say "I successfully found nothing matching your search criteria"