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.
Related
Am pretty new to OData.
Per my internet reading what I've gathered is Apache Olingo is better (vs OData4j) for Java implementation of OData service and OData consumer.
Can you please help me with sample code of Olingo service and Olingo consumer?
Any help in this regard is much appreciated.
Have a good one.
Thanks.
First you'll want to consult Olingo's documentation here. Their documentation is alright for basics but once you start extending it there's not much out there. As you can tell from no one answering this for 18 hours OData doesn't seem to be a hot topic right now.
If you want to create a basic service without JPA this is a good resource: OData Service with Olingo
If you want to create an OData service that uses JPA this is a good resource: OData JPA Web App. Also this one is helpful Olingo OData with MySQL.
Here's a document on how to create a client: Olingo Client We actually use Excel as a client which is quite nice for Excel users. However, there are times when Excel has compatibility issues with certain features (EDM Complex Types). Here's some good documentation on how to use Excel and OData
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.
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 am working on a web based EMAR application which we are building in DotNet. I have a requirement to make to Pharmacy Software's with my web based EMAR. Please correct me if I am wrong, I think I need to make a transfer engine which communicate with Pharmacy Software and my web based EMAR.
This is the basic of my requirement. Now let me allow to explain what I have to achieve.
In my EMAR there are Facilities and they have Patients (Residents) there. Now If a Pharmacy of a Resident add or edit in any medication in its own software then it should automatically appear in the medication profile of web based EMAR.
I am doing some research in this from last couple of days. I found "Mirth Corp" ( http://www.mirthcorp.com/products/mirth-connect ) and "IGUANA" ( http://www.interfaceware.com/iguana.html ) which provide this. But not sure how they can help me in this.
Can anyone help me here how fulfill this requirement?
Thanks
Rahul K
We are using WSO2 ESB to transfer HL7 messages (ADT messages for Patient Data) from one system to the other. As it is a ESB you can transform the HL7 (file based or over TCP-IP) in any other format (XML, text) over different transports like WebService, FTP, local file or whatever.
WSO2 is a really simple ESB and fully free & open-source. Just download and create a proxy (gets data), transform it (if you need) and send it to you application.
-- I'm not related to WSO2, so this is just my opinion ---
Of course you can use also other ESB like Mirth. Or here you can see a list of some open-source ESB. But you need to check if they have an HL7 adapter included.
If you don't want to use any ESB, there is the Java Implementation of HL7 with the HAPI library. Then you can do whatever you want with it.
Is there any reason why the default plug and play F# type providers to web services is soap based wsdl? Is it because of a lack of formal contracts in REST? Such that each REST api may differ significantly and hence making a general REST provider difficult to provide?
Type providers need machine-readable type schema to do their jobs well.
Type providers need schema. So you could use Open Data Protocol that is REST + schema. For that task you could use ODataTypeProvider that is already implemented.
I think that this is because there is no way to know how the API looks. Humans can read the documentation, but the Type Provider cannot. Other APIs have XML specifications, so they are easier.