This question already has answers here:
What is the difference between URI, URL and URN? [duplicate]
(4 answers)
Closed 7 years ago.
I understand it has something to do with databases but I am not exactly sure what it does.. I looked on the android developer page and they don't explain it very well.
I am not sure about the context but URI generally refers to Uniform Resource Identifier. See Wikipedia for more:
In information technology, a Uniform Resource Identifier (URI) is a
string of characters used to identify a resource. Such identification
enables interaction with representations of the resource over a
network, typically the World Wide Web, using specific protocols.
Schemes specifying a concrete syntax and associated protocols define
each URI. The most common form of URI is the Uniform Resource Locator
(URL), frequently referred to informally as a web address. More rarely
seen in usage is the Uniform Resource Name (URN), which was designed
to complement URLs by providing a mechanism for the identification of
resources in particular namespaces.
wikipedia
Related
I am confused here! I read a blog and it said in RESTful architecture,we can use more than one URI to represent a resource.
Is this right,since URI is use as identifier,it should be unique. Did I misunderstand something?
Sorry I am not going to post the link of that post because it is written in Chinese:)
Yes that is true. REST follows existing standards (aka. uniform interface constraint), now we are talking about the URI standard.
I think the simplest example about this is localhost. So imagine you have a REST service on http://localhost/api on your computer. Now by default you can reach the same service using http://127.0.0.1/api. So even the api root does not have an 1:1 relationship with the URIs in this case. In terms of the URI standard uniqueness means an 1:n relation between the resource and the URIs. This is different to the uniqueness term you are used to by relational databases. So in different words, a single resource can be identified by multiple URIs, but a single URI can identify only a single resource.
Here's an example URL:
/users/123/comments
Based on this URL, which term would best describe users? Is users the resource or is it a part of the resource. What would be the name of that part?
The same question goes for the other parts. Which terms would best describe 123 and comments?
Is there a term that would refer to the second part of RESTful URLs? It would describe 123 in /users/123 and purchases in /me/purchases.
REST is a Resource-Oriented. URLs represent resources.
In your example, /users/123/comments:
users is a resource.
123 is the unique identifier of an user.
In this case, comments are a sub-resource of users, but they are probably resources on their own (ex. calling /comments/{id})
About your second question, the format for /me/purchases is not the same as /users/123. And /me/purchases is probably a short URL for something like /users/{myid}/purchases where purchases are a sub-resource of users (and probably a resource on their own also, available by /purchases/{id}).
For more information, here is a video, that is not directly related to your question, but that is very well made and very interesting about REST web services.
In your example, http://example.org/users/123/comments points to a resource. A complete URI is an identifier for a resource.
Let me give you an extreme example,
/users/123/comments.xml
/users/123/comments.json
are two different resources.
The query string also identifies resources, so
/users/123/comments?format=xml
/users/123/comments?format=json
are also two different resources.
Resources do not map to entities. Resources are "some concept" that you wish to expose over HTTP and have identified with a URI.
In RESTful system URIs are opaque to the system design. A client of your system should not try and infer meaning from portions of your URI. A server can setup conventions to help it build a URI space, but these are private implementation details of the server.
There is no such thing as a RESTFul url. The term is a fabrication of framework designers and will just serve to confuse you.
This question already has answers here:
Encrypt IDs in URL variables
(5 answers)
Closed 7 years ago.
I'm developing a Web Site using ASP.NET MVC 3, Nowadays I need to encrypt the ID of my customer's URL. For example:
http://mysite.com/person?id=42
to something like that:
http://mysite.com/person?id=Dfjhasdfh33kASDG868365çkhg54sdSDFD
It need be secure.
When I say secure, It means hard to any one discover the correct ID
Is there any library to do that?
Many secure web payments one of then like paypal uses this type of approach:
https://paypal.com/br/webscr?info=CNS9tFsVM_tv4c18gHgZ3OMH2zblN7GWDQoyamVF3mzNh7vGDuhiKU3
If you REALLY want to encrypt the query param, it's very simple, just use any encryptor provided by .Net and then use an attribute or a httpmodule to decrypt the param.
The most important thing is to ALWAYS validate the request. If you can do it a POST with anti forgery token, do it. Then, always check the user credentials if that user has access to the protected resource.
It's not hard at all, but you have to take it slowly and handle every scenario you can think of. Use a white list approach: only those who meet some conditions are allowed.
One option would be to make your PK's that long with a randomly generated string or a unique identifier (GUID).
I've often seen "bis" appended to versions of protocols (eg v.34bis or httpbis).
What does "bis" mean or stand for?
A telecom engineer I know thinks it might be French in origin.
As others have already said, "bis" comes from "twice" or "repeat". It's used to indicate a second variant of something (although usually with only minor variations that don't warrant a new name).
In the context of HTTP, HTTPbis is the name of the working group in charge of refining HTTP. According to its charter:
HTTP is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial
issues. Additionally, after years of implementation and extension,
several ambiguities have become evident, impairing interoperability
and the ability to easily implement and use HTTP.
The working group will refine RFC2616 to:
Incorporate errata and updates (e.g., references, IANA registries, ABNF)
Fix editorial problems which have led to misunderstandings of the specification
Clarify conformance requirements
Remove known ambiguities where they affect interoperability
Clarify existing methods of extensibility
Remove or deprecate those features that are not widely implemented and also unduly affect interoperability
Where necessary, add implementation advice
Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications
It will also incorporate the generic authentication framework from RFC
2617, without obsoleting or updating that specification's definition
of the Basic and Digest schemes.
Finally, it will incorporate relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.
In doing so, it should consider:
Implementer experience
Demonstrated use of HTTP
Impact on existing implementations and deployments
The Working Group must not introduce a new version of HTTP and should
not add new functionality to HTTP. The WG is not tasked with producing
new methods, headers, or extension mechanisms, but may introduce new
protocol elements if necessary as part of revising existing
functionality which has proven to be problematic.
The last paragraph (emphasis mine) explains why they've used "bis" in this context, since they explicitly don't want a new version.
bis
The word (also used as a prefix or suffix) bis , applied to some modem protocol standards, is Old Latin for "repeat" (akin to Old High German "twice"). When a protocol ends with "bis," it means that it's the second version of that protocol.
Similarly, ter is from Old Latin meaning "three times." The suffix terbo in the V.xx modem protocol is an invented word based on the Old Latin ter and the word turbo (Latin for "whirling top" or "whirlwind") meaning "speed." V.32terbo is the third version developed of the V.32 modem protocol..
(from http://whatis.techtarget.com/definition/0,,sid9_gci211669,00.html)
what is the best way to support zeroconf names in the location segment of a URI design?
RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) makes no mention of zeroconf and i fear the URI syntax is not designed to work beyond DNS resolution.
the ideal answer syntax will:
conform to the generic URI syntax
handle zeroconf names with multi-byte characters
Here are some options:
dnssd://local/_printer._tcp/Fancy printer/
dnssd://Fancy printer._printer._tcp.local
These strings are IRIs, not URIs, in order to address i18n issues.
a nested URI is another approach that is backward compatible. a nested URI defines the location for use with discovery protocols like zeroconf.
see 'nested uniform resource identifiers' manuel urena and david larrabeiti
however i dont find evidence this approach in is wide use.
A universal resource identifier is a generic way to locate a resource. For internationalization, you may want to check on IRI, which is almost the same, but allows for full Unicode compatibility. The reason that it doesn't mention Zeroconf is that URI is a generalized protocol. Zeroconf may use URIs are part of its protocol for discovery, but URI will never use specific implementation in its protocol (you won't find ftp:, https:, mailto:, skype: etc in there either)
Zeroconf is a protocol to automatically configure your network and discover available services. It consists of three parts, address selection (part of IPv4/6), name resolution (mDNS) and service discovery (UPnP (Microsoft), DNS-SD (Apple)). Modern operating systems support all of this out of the box.
If we take UPnP, the discovery is done based on a URI, iirc. The returned information is given in XML. XML can be any Unicode encoding. If you're a device driver manufacturer, you can place any character in there. The final phase may be presentation, which is a URL but that's optional.
A URI / URL both support internationalized characters, but only escaped and not in the domain name part.
-- Abel --