I am trying to fetch data from a service that i donot know much about.
So i got its url like
http://ABC.com/ABC.svc
so i thouhgt to get metadata as
http://ABC.com/ABC.svc/$metadata
it gives me:
<EntityType Name="E1">
- <Key>
<PropertyRef Name="E1k1" />
</Key>
< Property Name="E2" Type="Edm.String" Nullable="true"
m:FC_TargetPath="SyndicationTitle" ..>
<ComplexType Name="OptionV1">
<Property Name="Value" Type="Edm.Int32" Nullable="true" />
... and a lot more.
How do i find out what should come next to ABC.svc/???
I want to write queries to access data. Can smebody point me to what should be my next steps?
and any learning resource on this query generation from metadata would be hlpful.
Thanks
There are two ways:
1) Using the service document. Navigate to the ABC.svc, that should return a service document, that is an ATOM Service payload which contains the names of the entity sets available from the service. For a sample of such you can go to http://services.odata.org/OData/OData.svc/. This should return a document with three collections (Entity sets). The href attribute is a relative URI to the entity set (relative to the xml:base which is usually the base of the service). So if for example your service has an entity set E1Set, then typically the address of it would be ABC.svc/E1Set.
2) Using the $metadata document and assuming the usual addressing scheme (note that this usually applies to the service but it doesn't have to). The $metadata document will define entity sets. Each of these is usually exposed by the service and typically follows the addressing scheme of ABC.svc/EntitySetName.
Once you navigate to the entity set, you should get back an ATOM feed with the entities in that set. The $metadata will help you recognize the shapes of the entities and the relationships.
Some services also have service operations or actions and so on. These are not exposed in the service document #1. Instead they are only visible in the $metadata as FunctionImport elements. They usually follow the addressing scheme of ABC.svc/FunctionImportName. But note that you might need to know something more about the service operation to be able to invoke it (what HTTP verb to use, what are the parameters, what it will do, and so on).
LinqPad provides a very simple means for getting started with OData services (assuming some familiarity with LINQ). If you will primarily be primarily consuming this application from .NET, I'd recommend starting with this application. You point it to the $metadata endpoint and it generates proxy classes which allow you to work with the OData service much like you would in a plain-old-.NET-app. On the Results Log tab, it will output the URL used to query the OData service, which you can then pick up and tweak in Fiddler. (For more about how to use OData + Fiddler, see this blog post.)
If you'll primarily be using the OData service from JavaScript, you might want to start by understanding the URI conventions better or by playing around with data.js.
Related
I have spent a lot of time trying to figure out what OpenAPI Links can be used for and how they relate to hypermedia links in the body of a response & it's doing my head in!
Lets say the simple class model below represents the business domain for which we have defined an OpenAPI spec that provides paths to navigate the instances of the various classes.
For example, if I perform a get of /borrowers/{id}, I would expect the response to contain both the properties of Borrower and a means to follow R1 or R2 to get the relevant set of Book instances.
Before OpenAPI 3 I would have constructed links to the relevant paths e.g.
/borrowers/{id}/loaned-books or /borrowers/{id}/reserved-books and included those as properties (hyperlinks) in the definition of the response body.
At runtime, if I followed those hyperlinks I would get an array of the relevant Books each of which had other hyperlinks.
So the OpenAPI Link questions are:
Are they a replacement for the need to generate hyperlinks in the response? I don't think so but in which case
What is the Runtime Expression Language (REL) for?
Are they just a means of defining hyperlinks in the API spec? Possibly but in which case does the response body definition still need to include properties for those links? Presumably their values still need to have the actual hyperlinks created on the server?
Given that the REL doesn't allow wildcards how do you define links when the response is an array of resources, each of which has an id to be used by the next operation?
Any help explaining links would be gratefully received.
Each item or property of wikidata has a persistent URI that you can obtain by appending its ID. For example, the property P1566 (representing GeoNames ID) has the following URI
http://www.wikidata.org/prop/direct/P1566
You can also access to this property P1566 by visiting other URLs below.
https://www.wikidata.org/wiki/Property:P1566
https://www.wikidata.org/entity/P1566
Why are there multiple URLs to represent the same concept in wikidata? What is the difference between them?
Wikidata (like most Linked Data services) makes a distinction between the resource itself, and the information describing the resource. In your example, http://www.wikidata.org/prop/direct/P1566 presumably is the identifier of the property itself, whereas https://www.wikidata.org/wiki/Property:P1566 is the identifier for a resource (a wiki page, in this case) that describes the property.
This distinction is important in a linked data context, because linked data (RDF) uses the URI to identify what it is making claims about. So for example, the RDF statement:
http://www.wikidata.org/prop/direct/P1566 rdf:type rdf:Property .
is factually correct, but :
https://www.wikidata.org/wiki/Property:P1566 rdf:type rdf:Property .
is not (it's a wiki page, not a property). Think Magritte: "It's not a pipe, it's a picture of a pipe".
The reason they all redirect to the wiki page in the end is simply that the HTTP content negotiation mechanism makes this happen: your browser sends a request for the resource, with HTTP headers that say what content type(s) it expects, the server inspects that, sees that the client expects HTML, and therefore redirect to the info page about the resource.
In all this, I simply have no idea why there is also a https://www.wikidata.org/entity/P1566 URI, by the way.
More info about how linked data URIs and content negotiation works can be found here: https://www.w3.org/TR/cooluris/ .
I'm new to Spring security. Now I'm reading its documentation. I have a question regarding to its filter chain url patterns:
As explained in the document:
it's possible to use multiple http elements to define different security configurations for different URL patterns. Each element creates a filter chain within the internal FilterChainProxy and the URL pattern that should be mapped to it. The elements will be added in the order they are declared, so the most specific patterns must again be declared first.
it also gives an example:
<!-- Stateless RESTful service using Basic authentication -->
<http pattern="/restful/**" create-session="stateless">
<intercept-url pattern='/**' access='ROLE_REMOTE' />
<http-basic />
</http>
what I don't understand is:
A URL pattern "/restful/**" is already configured for the http tag, it means all request matching this pattern will be handled by the filter chain inside this http tag. However why it gives a "match all" pattern: "/**" to the intercept-url tag?
Isn't it duplicated?
Also, if really want to give another pattern, isn't "/restful/**" better? Cause "/**" will match URLs that will not match "/restful/**" and thus not be handled by this filter chain.
Without the <intercept-url> tag within <http>, this declaration basically says that anyone can access any resource under the /restful/** path. The <intercept-url> here restricts access to users who have been assigned the ROLE_REMOTE role, which is quite different.
<intercept-url> patterns are relative to the enclosing <http> element pattern, so nothing outside the /restful/** path will be intercepted by this declaration.
The typical pattern is that you will have one <http> element with several <intercept-url> elements within targeting different URL patterns. Additional <http> elements can be useful when you want authentication and access control to behave differently, for example session management or authentication failure handlers for REST API endpoints.
I have to parse through xml which contain URI links to dbpedia.org. I have to extract rdf triples from those URI based on a given Ontology using Jena library. How do I resolve the Prefix programmatically in Java based on the ontology given.
The given ontology says that triples can be extracted by querying dbpedia.org. For all such triples the corresponding dbpedia resource is available to start writing the query. But the problem is how do I write the query with only its resource available. I have the properties to query. But I don't have the PREFIX for those properties
Although this may not answer the question directly, I had a whole load of URIs, some prefixed some not and I wanted them all unprefixed (i.e. written out in full with their prefixes resolved). Searching Google the most useful thing I came across was this question (first) and the JavaDoc so I thought I'd add my experience to this question to help anyone else who might be searching for the same thing.
Jena's PrefixMap interface (which Model implements) has expandPrefix and qnameFor methods. The expandPrefix method is the one which helped me (qnameFor does the reverse i.e. it applies a prefix from a PrefixMap to a string and returns null if no such mapping can be found).
Hence for any resource, to ensure that you have a fully expanded URI you can do
myRes.getModel().expandPrefix(myRes.getURI());
Hope this helps someone.
Your question is not very clear, so if this answer doesn't address your issue please edit your question to say more clearly what your problem is. However, based on what you've asked, once you've read an RDF file into a Jena model, in XML or any other encoding, the prefixes used are available through the methods in the interface com.hp.hpl.jena.shared.PrefixMapping (see javadoc). A Model object implements that interface. To automatically expand prefix "foo", use the method getNsPrefixURI().
Edit
OK, given your revised question, there's a number of things you can do to turn a simple property name into a property URI that you can use in a SPARQL query:
use the prefix.cc service to look at possible expansions of prefixes and prefix names (e.g. if you are given dbpedia:elevation, you can look it up on prefix.cc (i.e: http://prefix.cc/dbpedia:elevation) to see that one of the possible expansions is http://dbpedia.org/ontology/elevation
issue a SPARQL describe query on the resource URI to see which properties are returned in the RDF description, then match those to the un-prefixed property names you've been given
ask your data provider to give you full property names, or otherwise provide the prefix expansions, in order to save you from having to reverse engineer which properties he or she meant in the first place.
Personally I'd advocate the third option if that's at all possible.
I have a Rails app that needs to expose values from a database as a web service - since I'm using Rails 2.x, I'm going with REST (or at least try). Assuming my resource is Bananas, for which I want to expose several sub-characteristics, consider this:
- /banana -> give a summary of the first 10 bananas, in full (all characteristics)
- /banana/?name=<name> -> give all characteristics for banana named <name>
- /banana/?number=<number> -> give all characteristics for banana number <number>
- /banana/?name=<name>/peel -> give peel data for banana named <name>
- /banana/?number=<number>/length -> give length data for banana number <number>
I don't want to search for ID, only name or number. And I have about 7 sub-characteristics to expose. Is this RESTful?
Thanks for any feedback!
What Wahnfrieden is talking about is something called Hypermedia as the Engine of Application State (HATEOAS) - a central constraint of REST as defined by Fielding.
In a nutshell, REST application clients never construct URIs themselves. Instead, they follow URIs provided by the application. So, URI templates such as the ones you're asking about are irrelevent at best. You can make them conform to a system if you'd like, but REST says nothing about how your URIs need to look. You could, if you wanted to, arrange it so that every resource in your system was available from http://example.com/{hash}.
Publishing URI templates, such as the ones you're talking about in your question, introduces tight coupling between your application and clients - something REST is trying to prevent.
The problem with understanding hypermedia-driven applications is that almost nobody implements or documents their "RESTful" systems this way.
It might help to think about the interaction between a human and server via a browser. The human only knows about content and links that the server provides through the browser. This is how a RESTful system should be built. If your resources aren't exposing links, they're probably not RESTful.
The advantage is that if you want to change your URI system, for example, to expose the Banana "Peel" attribute through a query parameter instead of a nested URL, you can do it anytime you'd like and no client code needs to be changed because they're not constructing links for themselves.
For an example of a system that embraces the hypertext-driven constraint in REST, check out the Sun Cloud API.
I would use these:
/banana
/banana/blah
/banana/123
/banana/blah/peel (and /banana/123/peel)
/banana/blah/length (and /banana/123/length)
First, common practice for ReSTful URIs is /object_name/id/verb, with some of those absent (but in that order). Of course, this is neither required nor expected.
If all your names aren't made of digits, you don't have to explicitly have name in /banana/name/blah. In fact, if anything, it would be better to have id as identifier: /banana/id/123/peel. Hope this helps.
Parameters should only be used for form submission.
Also, URI naming schemas is totally unrelated to REST. The point of REST is to make related resources discoverable via hypertext, not out-of-band conventions, and only from a limit number of entry points. So your /bananas/ entry point might provide the summary info for 10 bananas, but it must also provide the URI for each of those bananas' details resources, as well as the URI to get the summary for the next 10 bananas. Anything else is just RPC.
It is good practice in REST to not use query parameters because query parameters don´t belong to a URL and in REST all resources should be addressable through a URL.
In your example /banana/?name=name should be /banana/name because you are referring a concrete resource.
Even I think /banana/?number=number/length is not good REST style, because you are selecting an attribute through a URL when you should retrieve the whole state with /banana/name . A difference could be /customers/1024/address to get the Customer 1024 address record.
HTH.
A more opt form for the route in url having query string is the plural form, as it is possible that multiple items are returned in the result. In this case, bananas, like bananas?color=yellow, sounds more appropriate.
On the other hand, the singular form banana, like banana/123, is good when fetching a specific resource's representation when its identifier is known and query string is not required.