WITSML+REST
Last month I promised some more depth on using WITSML RESTfully. I've posted a draft of a RESTful WITSML protocol. If you're a WITSML implementor you should read that draft, and please leave comments about it on this page.The protocol reproduces and enhances all the capability in the present WITSML SOAP API.
From the conclusion of that draft:
Servers can expose WITSML services using the principles that made the Web the most successful distributed application in history. Doing so increases the value of WITSML because users can leverage existing web technologies, like browsing, bookmarking, linking, and forms. Furnishing WITSML data objects with URI enables a host of new functionality. For example, semantic web descriptions of resources require URI; it will now be possible for a company to inventory metadata about the WITSML data objects it owns.
Wellstorm WSPpresently implements some, but not all, of this protocol, in order to support web clients -- but we're working on it. It's very easy to adapt existing server code to execute this protocol, since it conforms well to the semantics of the SOAP API. Let's hope more implementors will do so.
posted by hughw @ 11:56 AM
3 Comments:
Hugh, As a part of the automation use case we are having another look at the WITSML API and looking for a way to simplify things. I like the REST approach and can see how it takes advantage of the basic HTTP functionality to achieve most of what you need to do with data on a server. Do you have any thoughts about how this could be extended to do simple tima and depth range queries for objects? A well could easily have 100+ opsReport objects and it would be good to be abvle to query for reports within a date range.
Regards, John Shields
John -- we want to be able to ask the server for the URL of that query. This is what the ordinary web does. If you were on a web site and were looking at a list of 1000 items, they'd give you a web form to fill out that let you enter a date range. You press submit. One of two things happens.
a) the HTML form declared method="GET": Then the web browser constructs a query string. It takes the "name" attribute from each text field, pairs it with the values you typed there, and strings them all together and name value pairs, appends them to the form's "action" URL, and voila: There's the URL you can use to get the answer to your query. Pressing submit sends your browser there. You can also email me the URL.
b) the HTML for declared method="POST". The browser constructs the query string as above, but instead of appending it to the action URL to construct the new URL, it sends it as the body of a POST message, to the action URL. While the server could just respond with the answer to the query, another typical behavior is it returns 303 See Other with the Location header set to the query URL. In other words, the server can do the URL constructing itself, rather than allowing the browser to construct it.
The Simplest Thing That Could Possibly Work is like the case in (b), and is not much different from what we do now. We want clients to submit a "form" they have filled out that tells the server the query parameters. At present our form is a WITSML query template. In WITSML API, we send it by SOAP, but POSTing that "form" to a URL could give the same result. Wellstorm server does this btw. The service description document tells you the URL where you can POST plain old WITSML query templates.
Sure, we have to fix query templates -- they can't describe the queries we need to make. We probably already know the 10 most interesting query parameters: dates, lats and longs, etc. Any kinds of queries we can't think of in a few weeks, are just probably not in widespread use enough to justify standardizing. So we come up with new improved query templates -- they don't have to look like the query-by-example ones we use now. Then clients POST them to servers and get the response directly, or (better) the URL where they can go get the response.
Just to be clear: I don't think we ought to be using Xforms or Xquery. Xforms: attractive, but we cannot justify the complexity. Xquery: a great burden on implementors.
Post a Comment
<< Home