Are both of Metadata Document and Service Document mandatory in OData V3?
According V3 core Protocal specification in Chapter 10.1.2, it said that OData services MUST expose a Metadata Document which defines all data exposed by the service.
So I believe Metadata Document is mandatory in OData V3, right?
But what about Service Document in V3?
Thanks for anyone's help,
According to the v3 spec:
2.2.3.7.1 Service Document
For a client to interact with a data service, it needs to discover the locations of the available collections of resources. AtomPub [RFC5023] defines Service Documents to support this discovery process.
The ServiceRoot of a data service MUST identify the Service Document for the data service.
More importantly, the general concept of a service document is a really important and fundamental REST API concept. REST says that there should be a single entry point that allows a generic hypermedia client to traverse the service. This would be a great time to paraphrase George Orwell: all REST principles are important but some are more important than others. Having a service document will be one of the "more important" principles if you care about generic OData clients like Excel.
Related
At the moment i still only have about 2 months of experience in UI5. i developed a little sample-app, used sap gateway builder to pass my requests to sap backend.
Now my employer asked me to research the possibility to access two different backends (one sap, one nonsap) via odata from the same app. After a little reading and thinking i came to the conclusion that it would be best to access both backends from a single gateway.
Since ive already worked with sap gateway, i wonder if there is a way to access nonsap backends with sap gateway? Are the better options?
Or is my current approach complete wrong and i should think about a whole other way?
It depends on your approach and the non-sap-system:
Is the non-sap-system accesible via Webservices? Then use second data model (e.g. JSON/ODATA) within SAPUI5 by loading data via webservices after initial loadup of your application.
Is the non-sap-system connected to SAP? E.g. via RFC or another technology, then you can read data from the other system during calling your initial Gateway service and simply call your RFC function module in your method.
From my opinion you will not achieve an 'easy' way to read both via one single SAP NetWeaver Gateway.
Not sure why you would want to access a non-SAP oData service via SAP Gateway. On the other hand you may want a router of some sort so that all services are exposed on the same network location and then incoming requests are routed to the appropriate backend for action.
You may also want to "mash-up" the SAP and non-SAP services into some sort of new service. In that case maybe look to some of the API management tools like Apigee to help you achieve that.
I have been playing around with the RPC package in Dart which makes it easy to add a Document Discovery service to Dart server.
After a bit of Googling I found out about the API Discovery Service https://developers.google.com/discovery/ which explained how to create client code for a given Discovery Document.
I then found Google Cloud Endpoint which looks like the server end of the a Document Discovery service. Is this true.
My real question is that I would like to use the Document Discovery service on a standard web site that is based on (say) Spring and running (say) an embedded Jetty server? Is this possible or would my application be intertwined with the App Engine Technology?
You application just needs to provide a Document Discovery service.
It shouldn't be to hard to get the information what is expected out of the source of https://pub.dartlang.org/packages/discovery_api_client_generator which is the Dart client which generates Dart client code from discovery documents. As far as I know your service doesn't even need to provide the discovery documents. The discovery_api_client_generator package can also use discovery documents stored locally but the service is of course the preferred way if you want to make it available to everyone.
I would see it as equivalent to SOAP which also allows to create client code from meta-information provided as XML.
Also the shelf_rpc package doesn't need to run on AppEngine or Managed VM. You can run it locally or on any server you want.
I'm a little bit confused that metadata doucment in OData Service.
As odata-v4.0-part1-protocol doc mentioned, there are two well-defined resources that describe its data model, a service document and a metadata document.
I want to know if that means both of these two resources must be implemented during development of OData Services, or developers just only need to implement one of them by their own choices?
I do appreciate anyone's help.
Thanks
Not necessarily. According to the "13.1 OData Service Conformance Levels" of OData V4 spec:
for minimal conformance level "MAY publish metadata at $metadata according to [OData-CSDL] "
for intermediate conformance level " SHOULD publish metadata at $metadata according to [OData-CSDL]"
for advanced conformance level "MUST publish metadata at $metadata according to [OData-CSDL]".
In other word, this means metadata is NOT a must for OData V4 service but service document is a MUST. If you have a deeper understand of OData, there are two kinds of OData libraries -- server and client, the metadata document of OData is for advanced client to know more about the service(models, types and so on). So having metdata document or not actually depends on whether you want your service to be talked to as much clients as possible.
I'm new to the OData protocol.
I saw that it seems like there are 2 types of well-defined resources that describe the OData Service Data Model, which are Service Document and Metadata Document.
But I want to know that if both of these two resources can be found at the OData Service definitely / for sure?
Since I did not see any restriction from the OData specifications that OData Service must fulfil these 2 resources together during implementation, I guess that there is only one type of Service Data Model that can be found from service.
I really appreciate if any one can help to clarify it.
Thanks!
It depends on which libraries is used to implement the OData service. For example, if the service is implemented using ASP.NET Web API for OData or RESTier, the two documents will both exist for sure.
I have recently discovered OData & the new WCF Web APi library on codeplex. The web api allows me to expose results as IQueryable, which allows me to expose URL's in the OData format. Myn question is what is the difference between this and a regular OData Service, I read the following blog post http://phejndorf.wordpress.com/2011/07/15/wcf-web-api-odata-format-doesnt-mean-odata-service/ but I am unsure what the OP means.
Thanks
The WCF Web API supports adding a [QueryComposition] attribute to a function so you can use the OData $filter=.. style of filtering data on the server and sending only a subset back to the client.
With OData, I should say WCF Data Services, there is much more that just querying. You can do all of the CRUD operations. It also means you are using the OData, is an AtomPub superset, protocol where with WCF Web API you do whatever you like. OData is actually a hypermedia format that contains metada, relations etc.