I am trying to find examples of URI's with multi-indexed resources to see what they would like so I can try to start using them. What would an example URI look like?
Related
I found a very little information on this matter. What is the difference between dereferenceable and non-dereferenceable URIs? What does it mean to dereference a URI? How does the URI change after it has been derefenced?
When reading about linked data at Wikipedia, it is said:
Use HTTP URIs so that these things can be looked up (interpreted, "dereferenced").
This makes it sound like every individual that can be found with the HTTP URI, eg "can be looked up" can be dereferenced? But not all URIs are derefenceable.
The simple answer is that if you can fetch a resource behind a URI by using exactly that URI, that URI is dereferenceable. This formulation means that only URLs are (potentially) dereferenceable and URNs aren't.
An extended definition is that all URIs you can map to a resource can be considered dereferenceable. For example, if you can map the URN urn:isbn:0451450523 to a book resource, then you may stretch the definition of dereferenceable URIs to include such URN (I wouldn't).
While on the topic, I think it's far better to mint URNs when your Linked Data resources are not dereferenceable (e.g. using an OBDA tool like Ontop) as to not confuse the consumers.
If you are looking at a quick way to make Linked Data resources dereferenceable, you can look at http://wifo5-03.informatik.uni-mannheim.de/pubby/
When I was digging DBpedia and trying to learn more about Linked Data, I have seen that DBpedia is redirecting from http://dbpedia.org/resource/Rome
to http://dbpedia.org/page/Rome.
I wasn't able to find any reason for that and I would like to learn why this is happening.
The /resource/ URI represents the thing.
The /page/ URI represents the human-readable document about the thing.
The /data/ URI represents the machine-readable document about the thing.
(This is the HTTP status code 303 approach. More details.)
So, if you want to say something about the city/comune Rome, you have to use the /resource/ URI.
In MVC and WebApi you can add parameter constraints to your routes (see http://www.asp.net/web-api/overview/web-api-routing-and-actions/attribute-routing-in-web-api-2#constraints). You can even use regular expressions for the parameter constraints. However, I'm wondering if it's possible to use regular expressions to handle API versioning where many routes could/should route to the same action.
For example, I'm trying to version my API in the actual URI like this:
/api/v3/SomeResource
Where v3 indicates that it's version 3 of the API. If I'm on version 3 of my API it is likely that many of the actions have been unchanged throughout all three versions and would hence need to respond to:
/api/v1/SomeResource
/api/v2/SomeResource
/api/v3/SomeResource
Therefore, I would like to just be able to put a regex in my route attribute like this:
[Route("api/v(1|2|3)/SomeResource")] but it appears as though it doesn't treat the v(1|2|3) as a regex and instead treats it as a literal. In other words, a request to /api/v1/SomeResource isn't going to this action.
Is it possible to accomplish what I'm trying to accomplish? is there a way to put a regex in my route?
Thanks in advance!
Take a look at this:
[HttpGet, Route("Api/v{version:int:regex(1|2|3)}/SomeResource")]
Reference:
http://sampathloku.blogspot.com/2013/12/attribute-routing-with-aspnet-mvc-5.html
No, it is not possible. Per MSDN.
A URL pattern can contain literal values and variable placeholders (referred to as URL parameters). The literals and placeholders are located in segments of the URL which are delimited by the slash (/) character.
Nor is it particularly useful in this case, because you would typically route each API version to a separate controller. Therefore, each version would require a separate route, not a single route that matches all versions.
The document which you have already linked has a section that specifically covers API versioning (although it doesn't provide much detail).
Once I got the servlet response,I need to check what are the resources involved in it.
Like the below
1) What is JSP/HTML's relative path,name which is coming as a servlet response
2) What is the Images/CSS/Scripts involved in the response view files (JSP/HTML)
Can filter be useful at this point or any other approach, if it is then how? Any guidelines will be great help.
On the Microformats spec for RESTful URLs:
GET /people/1
return the first record in HTML format
GET /people/1.html
return the first record in HTML format
and /people returns a list of people
So is /people.html the correct way to return a list of people in HTML format?
If you just refer to the URL path extension, then, yes, that scheme is the recommended behavior for content negotiation:
path without extension is a generic URL (e.g. /people for any accepted format)
path with extension is a specific URL (e.g. /people.json as a content-type-specific URL for the JSON data format)
With such a scheme the server can use content negotiation when the generic URL is requested and respond with a specific representation when a specific URL is requested.
Documents that recommend this scheme are among others:
Cool URIs don't change
Cool URIs for the Semantic Web
Content Negotiation: why it is useful, and how to make it work
You have the right idea. Both /people and /people.html would return HTML-formatted lists of people, and /people.json would return a JSON-formatted list of people.
There should be no confusion about this with regard to applying data-type extensions to "folders" in the URLs. In the list of examples, /people/1 is itself used as a folder for various other queries.
It says that GET /people/1.json should return the first record in JSON format. - Which makes sense.
URIs and how you design them have nothing to do with being RESTful or not.
It is a common practice to do what you ask, since that's how the Apache web server works. Let's say you have foo.txt and foo.html and foo.pdf, and ask to GET /foo with no preference (i.e. no Accept: header). A 300 MULTIPLE CHOICES would be returned with a listing of the three files so the user could pick. Because browsers do such marvelous content negotiation, it's hard to link to an example, but here goes: An example shows what it looks like, except for that the reason you see the page in the first place is the different case of the file name ("XSLT" vs "xslt").
But this Apache behaviour is echoed in conventions and different tools, but really it isn't important. You could have people_html or people?format=html or people.html or sandwiches or 123qweazrfvbnhyrewsxc6yhn8uk as the URI which returns people in HTML format. The client doesn't know any of these URIs up front, it's supposed to learn that from other resources. A human could see the result of All People (HTML format) and understand what happens, while ignoring the strange looking URI.
On a closing note, the microformats URL conventions page is absolutely not a spec for RESTful URLs, it's merely guidance on making URIs that apparently are easy to consume by various HTTP libraries for some reason or another, and has nothing to do with REST at all. The guidelines are all perfectly OK, and following them makes your URIs look sane to other people that happen to glance on the URIs (/sandwiches is admittedly odd). But even the cited AtomPub protocol doesn't require entries to live "within" the collection...