What is meaning/difference of Level 2 and Level 1 in XMLHttpRequest document provided by W3C
what is that Level No represents in that W3c provided document?
XMLHttpRequest Level1
When a specification is developed at W3C, multiple major revisions of different maturity can exist simultaneously. So for example Level 1 could be the more mature version (closer to becoming a Recommendation), and Level 2 might define more features, but be further away from becoming a REC.
In the specific case of XHR (based on the "Specification history" section of the spec):
The XMLHttpRequest object was initially defined as part of the WHATWG’s HTML specification.
W3C XMLHttpRequest Level 1 was an attempt to push the description of the functionality already implemented by MS Internet Explorer (and copied by other browsers) through the W3C Process, designed to:
support multiple specification development methodologies
maximize consensus about the content of stable technical reports
ensure high technical and editorial quality
promote consistency among specifications
facilitate royalty-free, interoperable implementations of Web Standards, and
earn endorsement by W3C and the broader community.
Since the process of becoming a W3C recommendation is rather slow, most improvements that were yet to be implemented were defined in a separate document, W3C XMLHttpRequest Level 2, which was intended to become a W3C Recommendation later than Level 1 and to eventually supersede the Level 1 version.
At some point, the maintainers found that the snapshot-based development approach didn't work very well, decided to abandon the attempt to publish the documents as W3C-endorsed recommendations and continued to develop a single specification, WHATWG XMLHttpRequest Living Standard.
Related
How architecturally sound and up to industry standards nesting resource representations in REST APIs is, especially when it comes to nested lists of resources (like books of an author)?
I'm interested in finding links to authoritative sources that answer to this question.
The authoritative source for REST is the dissertation of Roy Fielding, based on work he did during the standardization of HTTP/1.1 (RFC 2068, RFC 2616, etc) in the 1990s.
REST defines resource ("Any information that can be named can be a resource..."), and requires that all resources understand messages the same way (uniform interface) but does not actually constrain your resource model.
"RESTful", historically, is context sensitive; in practice it means something like "more like REST than our current designs". In the web services community, it meant "more like REST than WS-* and SOAP". In Rails, it meant more like REST than the resource models that were recommended prior to Rails 1.2. And so on.
If what you are interested in is describing the relationship between a resource that is a collection and a resource that is an item in that collection, then the standard you want is RFC 6573.
But again, it doesn't tell you how to design the resources, or how to design the identifiers for those resources -- it just tells you how to indicate a relationship between them.
As far as I understand the web resource is something abstract identified by the IRIs and accessible through the web. What dereferencing the IRI gives back is the representation of the actual state of the identified resource, this is why it is called representational state transfer. I don't remember any standard that discusses nested resources. Maybe RDF is the closest what you are looking for. In practice if we follow RDF concepts, then to answer a GET request the REST API responds with a representation of an RDF subgraph starting with the resource indentified by the giving IRI and it can be any level deep. Nestedness is not something I would consider here, because it is a graph, not a hierarchy, it is sort of expanding relationships between resources or returning hyperlinks the API consumers can follow to do the exact same thing.
Not sure if this helps. I did not find any RFC beyond what VoiceOfUnreason's answer contains, I remember to read explicitly about web resources and identifying real things with hashtags or non-dereferenceable IRIs in an RFC 5+ years ago, but I have no idea which one it was. Maybe it was the Lanthaler dissertation or the SemWeb document VoiceOfUnreason suggested. What is certain it was somehow connected to the semantic web and RDF.
REST’s identification of resources constraint requires that resources
are identifiable so that they can be accessed and manipulated via
generic interfaces. On the Web, resources are identified by IRIs [44].
Since a resource may represent con- cepts which cannot be serialized
into a byte stream (e.g., persons or a feeling), resources are not
manipulated directly. Instead, REST is built on the concept of
manipulation of resources through representations; i.e., an additional
layer of indirection in the form of resource representations is
introduced.
https://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf
On the Semantic Web, all information has to be expressed as statements
about resources, like the members of the company Example.com are Alice
and Bob or Bob's telephone number is "+1 555 262" or this Web page was
created by Alice. Resources are identified by Uniform Resource
Identifiers (URIs) [RFC3986]. This modelling approach is at the heart
of Resource Description Framework (RDF) [RDFPrimer]. A nice
introduction is given in the N3 primer [N3Primer].
Using RDF, the statements can be published on the Web site of the
company. Others can read the data and publish their own information,
linking to existing resources. This forms a distributed model of the
world. It allows the user to pick any application to view and work
with the same data, for example to see Alice's published address in
your address book.
https://www.w3.org/TR/cooluris/#semweb
So what I want to say that what you see in the HTTP response is not the resource itself, just a representation of it and its relationship to other resources.
REST does not have a constraint which tells you how verbose that response must be. It just tells you that you must use hyperlinks to connect resources and that you must use standard MIME types and document your API. At least this is how I interpret the uniform interface constraint.
I think the question is very good, because this part of the architecture is open and there were many questions in the past years which ask how to use the URIs for querying nested resources. The answer is always that REST does not cover it, the URI and URI template standards don't cover it either. There are standards like OData and Hydra, which have suggestions, but it is just up to you. Your problem is connected to it, because it asks how verbose a response to such a query can be. It is not covered as well as far as I can tell, but what is certain that it can and must contain at least hyperlinks to other resources. RDF allows describing several resources in a single document, so if we extend the RDF approach to REST, which does not say this is forbidden, then I guess we can do it.
From practical perspective for example a collection is a sort of nested resource too and if the API consumer would send a dedicated request for every collection item just to know basic things like product names, then it would be wasting resources. Normally we respond this kind of requests with a single HTTP response or multiple ones with 25-50-100 items on a page. It does not make much sense from usability and scalability perspective to give hyperlinks to the consumer for each item and force them to follow those links one by one. In fact we like to respond with the exact view model the consumer needs and design APIs this way. I think the same is true for nested properties as well. From RDF perspective these responses represent a subgraph of a massive resource graph, which are managed by the REST service and by for example RDF vocabulary maintainers like OWL, Schema.org, etc.
So to have a one sentence answer: the representation of "nested resources" is not covered by REST and as far as I know not covered by standards like HTTP and URI either, but currently it is the best practice to use them and MIME types we frequently use for REST e.g. HAL+JSON or RDF/JSON-LD support nested representations too, so I would say yes.
Finding definitive information on ORTC seems difficult, and finding examples even more so. I need to send strings between iframes and was looking into using WebRTC but in order to support Windows Edge I have been looking into ORTC. I wanted to see if anyone had successfully used some sort of data channel with ORTC in Windows Edge. I thought ORTC was specifically for Edge but it seems to define a data channel but Edge does not implement it.
The information I have come across leads me to believe that ORTC cannot do data channels, despite the fact it is listed in their API.
RTCDataChannel defined in the API, section 11.3 http://publications.ortc.org/2016/20161202/)
The RTCDataChannel interface represents a bi-directional data channel between two peers.
But at https://learn.microsoft.com/en-us/microsoft-edge/dev-guide/realtime-communication/object-rtc-api I found:
Since Microsoft Edge does not implement the data channel, the RTCDataChannel and RTCSctpTransport objects are not supported.
and
Microsoft Edge currently does not support any of the DataChannel functionality currently defined in the ORTC spec.
Please offer additional resources I can research in order to have a definitive answer. Also helpful would be any resources stating whether Windows Edge will in the future be supporting this.
According to their roadmap, ORTC Data channels are "Under consideration".
Roadmap Priority: Low — We are still evaluating this technology. There
may be significant spec stabilization, foundational work, or
additional community input required before we can begin development.
But the real question is:
Why do you need webRTC in the first place?
You said that you need to send strings between iframes.
Are the iframes loaded on the same page?
If the answer is yes, you don't need webRTC at all. Take a look at the postMessage API instead.
Currently i'm working in a on-line payment company, i need to implement a access control system. I used XACML for experimental purpose 2 years ago, and used it in a management system(based on Balana's XACML implementation). I noticed XACML Version 3 specification hasn't been updated since Jan 2013, i wonder whether this specification is still under maintenance. If not, does anyone know any alternative?
What David says is correct. In addition, the OASIS XACML Technical Committee (TC) has just voted to hold a public review of Errata for XACML 3.0. The review should start within a few days. The corrections are minor, but it does show we are maintaining the documents and getting input from the field.
Although no one is currently working on them, there are several unfinished Profiles I would like to see completed. One is to extend the JSON format for XACML to cover the policy language. It currently only covers only the decision request protocol. Another is the ALFA policy language which is a more user friendly, JSON-like language originally developed by Axiomatics, and endorsed by the TC.
For people who want to use XACML, in addition to several excellent commercial products, there are at least two other open source implementations in addition the the WS02 - Balana one mentioned above. Forgerock has one and there is another originally developed in house at ATT. The later one was contributed to the Apache Incubator, but failed to gain traction and was mothballed. However the original code is still freely available under Apache license.
Finally I should mention that I have proposed various ways to integrate XACML with token-based authorization schemes such as OAuth. However this has not gone past the research stage.
Yes, XACML is still very much active. The standard, in version 3, is mature and right now no one is working on XACML 4.0. Given XACML 3.0 is a standard, there won't be changes made to 3.0. Either we go to 3.1 or 4.0. There are enhancements we are thinking of for a 4.0 version but this is not the focus for now.
The focus is on profiles, both technical profiles (such as the JSON profile of XACML) and business profiles (such as the Export Control profile of XACML).
Disclaimer: I work for Axiomatics, the leading XACML implementation. I am also a member of the XACML Technical Committee.
We see more and more requests for Attribute Based Access Control and XACML in the marketplace especially in financial and healthcare
The current Swagger spec claims that Swagger is used to describe and document RESTful APIs. I think this is not the case rather I think Swagger is useful for simply describing a HTTP API for a few reasons:
The Swagger spec has elements like Path and Definition but they don't clearly map to the REST data elements like resource, representation, and media types. My thought is that to effectively describe a REST API, you should be required to define the explicit REST data elements in the context of your API.
Hyperlinks are not first class objects in the Swagger spec and thus hyperlinks and their critical descriptive attribute, link relation, can easily be left out. In fact, hyperlinks are not mentioned at all.
HTTP paths are at the front-and-center which seems to be a clear violation of a point Fielding made in his famous blog post:
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server)
Essentially, I think APIs defined using the Swagger 2.0 spec leads you to design an API that isn't constrained by HATEOAS which would violate REST.
Is this correct or am I missing something?
I absolutely agree. Swagger is not well suited for defining truly REST compliant APIs. The problem is that people define REST in a lot of different ways. The Richardson Maturity Model helps describe these different definitions.
Level 0 REST APIs pipe all requests through one URI and one HTTP method. This level includes any API that uses HTTP no matter how limited. In practice, people rarely call this REST anymore, but it does happen (probably for marketing reasons).
Level 1 REST APIs employ many URIs, but still only use one HTTP method (usually POST). Again, in practice, this rarely called REST anymore, but there was a time when it was common.
Level 2 REST APIs are where the concepts of resources and uniform interface are introduced. These APIs have URIs that represent resources and use the HTTP methods to perform CRUD operations on those resources. In practice, people started referring to this as RESTful to distinguish it from Level 1. I credit Ruby on Rails for popularizing this interpretation of REST, but I can't back that up. In any case, when Swagger claims to be for describing RESTful APIs, Level 2 is the definition they are referring to.
Level 3 REST APIs are fully compliant with the REST architectural style. In particular, they are characterized by using HATEOAS. All of the concerns you laid out in your question aren't taken into account until this level. In practice, some people have started calling these Hypermedia APIs to distinguish them from the now entrenched definition of RESTful as referring to the Level 2 definition.
I would say that your understanding of REST is more "mature" than that used by Swagger and therefore, you will only be frustrated trying to use it (I speak from experience). My personal choice for defining Hypermedia APIs is JSON Hyper-Schema. It can't match all the great tools Swagger has, but it allows me to write APIs at Level 3. That's more than I can say for any of the popular API definition languages out there.
My question is the following: when marking up an organization, business or brand with microdata and schema.org, should I use as a global identifier it's official webpage URL? Is there any kind of better reference that I could use (like IMDB for movies or actors)?
I'd like to know if there's any standard, convention or common practice recommended.
It would be better to use some kind of controlled vocabulary (e.g. VIAF) that uniqely identifies the organization in question.
The choice of identifiers is part of the explanation of REST. http://www.infoq.com/articles/rest-introduction
Inspect closely the first principle (for convention), though it is in broader terms of resources rather than specific to org/biz/brand. REST is the thesis that started this trend. Microformats accordingly makes use of rel="profile" link tags. The concept is further expanded at http://purl.org/ so, if IMDB, for example, switches to W3 like W3C did, then in the future this will minimize the impact on the application you're making right now. RDFa Dublin Core vocab's use of this is seen in the profile at http://www.w3.org/2011/rdfa-context/rdfa-1.1.html.
(For references) Applications serving general public or open initiatives such as academic support might be better served by these profiles, however when operating a site for commercial purposes, building application-specific "custom" profiles considering various legal matters identified, that should perform reliably with PURLs, might be advantageous to build credible reputation.
Finally, WHATWG considers prefixes too advanced and HTML5 for newbies only, so the support for W3's XHTML xmlns/RDFa prefix is dropped in microdata. This compels us to reuse long-form URLs for schema.org business/org/brand resources with microdata syntax. The "custom" profile then serves as mere good-will when picking up from where tasks are wrapped up, otherwise a more variety of items might appear in the content than actually intended, owing to mix-ups.
The good news is, Google supports schema.org usage as a vocab in RDFa syntax. So considering RDFa as an already "living" standard that originated in W3 spec, as per the (non-)commercial nature of application, defining PURL for scope namespaces, profiles exhibiting prefixes, and syntax (of official web-page or substitute IRIs) as per target processors is the way to go. Currently no vocab besides schema is processed as microdata, and schema in RDFa isn't supported by anybody but Google!