+1 this makes sense, though we retrofitted OMG RLUS onto FHIR, rather than
it being our logical basis. But we simplified it a lot. Still, following
the same pattern would make sense.
Grahame
On Wed, Jan 21, 2015 at 9:22 AM, Heath Frankel
heath.frankel at oceaninformatics.com wrote:
I too
Hi Bert,
So, if the content contains the information that no person with that ID
is in the system, then that is information, everything went well, the
class did its work without error, then that is not an error, and one
could argument that 200 should be returned, or maybe 204, and not 404,
Although the the stock market-information is a data-object, it is
generated by a service, and because Rest is (mis)used to communicate
with services the service must be seen as the addressed resource.
If the service is out of order, or the address to the service is
misspelled a 404 would be in
Hi Thomas,
The interesting question is: what style of service should be used for
e-health business entities, like active care plans, managed medication
lists, and order management, which all need much more complex APIs than
just 'get'? FHIR is not designed for this kind of thing, and it's
I too have looked how the approach used by FHIR could be applied generically to
openEHR, but at the entry level using TDDs. I actually went up one level and
considered the principals of the HL7-OMG RLUS specification, which is the
logical basis of FHIR before they hard coded the resources. RLUS
The approach I took with my FHIR like API was to have a named query with know
parameters and result columns. This could be registered internally using AQL or
hard coded. This all comes from FHIR principles as they allow registering
queries and then executing them.
Regards
Heath
On 20 Jan
://cabolabs.com
From: heath.fran...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
CC: openehr-technical at lists.openehr.org
Subject: Re: CRUD Restlet
Date: Tue, 20 Jan 2015 22:30:47 +
The approach I took with my FHIR like API was to have a named query with know
parameters and result
Ok, you are right, but http is a very generic application layer, not to
designed to serve specific application needs, but designed to serve web
servers which only serve documents.
As you know, a web server is a very generic application, which, from the
time Http was designed, was only recource
I checked on how the large companies like Google, Amazon, PayPal, github do
it.
They all have a hybrid solution. They all use an own error schema was
verbal terms, sometimes hierarchical, and they all map their errors to the
http numerical status schema.
This means that a query with no result is
I just had some extra information.
A query with no result would have status 200, for example,
/parties/John+Doe.
When an identified resource is queried, and there is no result, than the
404 will be applicable, for example /party/123456
Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees
Hi Bert,
Sorry for my bad english.
I think that any aproximation is a viewpoint of a problem and that you
can solve the same problem from different viewpoints, using different
paradigms. The problem is to choose the optimal and when you have no
options that mix differents paradigms to find the
Thank, Isabel,
You are right, you and others have put me on the right track, I know now
how to proceed
best regards
Bert
On 19-01-15 09:07, Isabel Rom?n Mart?nez wrote:
Hi Bert,
Sorry for my bad english.
I think that any aproximation is a viewpoint of a problem and that you
can solve the
I've managed not to respond for some time but this discussion got to a
point where I can't help commenting :)
REST is a fact of the industry, due to whatever mysterious dynamics that
pushes various solutions down our throat as we get old in front of our
computers. So we live with it.
This does
I will just add that if you are making a server you probably want to
take a look and how FHIR does things. They have some pretty cool ideas
for common problems that you can probably reuse (e.g. using atom for
query responses)
2015-01-19 11:25 GMT+01:00 Seref Arikan serefarikan at
The medrecord openEHR server is also based on REST and worth looking at.
There was a lot to learn from for me as the API is pretty neat.
Best,
Birger
Am 19.01.2015 11:29, schrieb Diego Bosc?:
I will just add that if you are making a server you probably want to
take a look and how FHIR does
Birger and Diego,
Thanks for the useful pointers. I'll take these as starting points to see
how healthcare IT embraces REST.
Best regards
Seref
On Mon, Jan 19, 2015 at 10:31 AM, Birger Haarbrandt
birger.haarbrandt at plri.de wrote:
The medrecord openEHR server is also based on REST and worth
Hi all,
I agree with Diego -stay close to FHIR, if only because it will reduce
the burden on developers. I think there are some discussions about
dropping atom for bundles though.
As well as the Medvision360 api that Birger has pointed to, the crews
at Code24 and Ocean/ Lockheed Martin have
Hi Seref,
You are of course correct that FHIR or any other RESTful approaches
may struggle in more complex scenarios but I think there is increasing
evidence that simpler approaches can bring immense benefit and are an
order of magnitude easier to implement for non-specialist developers.
In the
Niet een slecht advies: Kijken bij FHIR van HL7
GF
Gerard Freriks
+31 620347088
gfrer at luna.nl mailto:gfrer at luna.nl
On 19 jan. 2015, at 11:29, Diego Bosc? yampeku at gmail.com wrote:
I will just add that if you are making a server you probably want to
take a look and how FHIR does
Hi Ian,
Thanks for the response. Just to clarify: as I've written, REST works for
some simple cases and delivers an economic advantage as you've also
expressed in the form of getting non specialist developers involved.
I for one am happy to see FHIR exploring this, which is apparently
delivering
On 19-01-15 12:06, Gerard Freriks (priv?) wrote:
Niet een slecht advies: Kijken bij FHIR van HL7
I will check that
GF
Gerard Freriks
+31 620347088
gfrer at luna.nl mailto:gfrer at luna.nl
On 19 jan. 2015, at 11:29, Diego Bosc? yampeku at gmail.com
mailto:yampeku at gmail.com wrote:
On 19-01-15 11:31, Birger Haarbrandt wrote:
The medrecord openEHR server is also based on REST and worth looking
at. There was a lot to learn from for me as the API is pretty neat.
I will check that too, thanks for the links
Bert
-- next part --
An HTML attachment was
Hi,
On 01/19/2015 11:31 AM, Birger Haarbrandt wrote:
The medrecord openEHR server is also based on REST and worth looking at.
There was a lot to learn from for me as the API is pretty neat.
Thanks. We do our best to make the REST API of MedRecord as simple as
possible. We try to base the
Thanks Ralph
;-)
On 19-01-15 13:10, Ralph van Etten wrote:
Hi,
On 01/19/2015 11:31 AM, Birger Haarbrandt wrote:
The medrecord openEHR server is also based on REST and worth looking at.
There was a lot to learn from for me as the API is pretty neat.
Thanks. We do our best to make the
Ralph van Etten wrote:
This has lead to our current version of MedRecord (which is still work in
progress) and can be found here:
https://mr.dev.medvision360.org/mr/apidocs/#!/
Hi Ralph,
That link doesn?t work. It displays this:
{error:406,message:The resource identified by the request
Works for me with the latests versions of chrome and firefox (windows)
Am 19.01.2015 13:44, schrieb Peter Gummer:
Ralph van Etten wrote:
This has lead to our current version of MedRecord (which is still work in
progress) and can be found here:
https://mr.dev.medvision360.org/mr/apidocs/#!/
Hi Peter,
This has lead to our current version of MedRecord (which is still
work in progress) and can be found here:
https://mr.dev.medvision360.org/mr/apidocs/#!/
Hi Ralph,
That link doesn?t work. It displays this:
{error:406,message:The resource identified by the request is only
Hi Ralph,
Mac OS X 10.9.5 with Safari 7.1.2.
The first time I clicked on the link it asked me for a certificate, which
seemed pointless to give it for API docs so I clicked Cancel. Then it displayed
the error.
On subsequent attempts it goes straight to the error. I guess the browser must
be
Hi,
On 01/19/2015 02:10 PM, Isabel Rom?n Mart?nez wrote:
I do think the REST architecture style is better than most SOAP, CORBA
and ESB solutions
Sounds too categorical to me!! you must study case requirements deeply
and you could not affirm this for every case!!
Sure, but I was talking
Hi Bert,
Thank you for proposing an interesting discussion whether http
response status should be included to API result or not.
I found this similar discussion on stackoverflow.
http://stackoverflow.com/questions/942951/rest-api-error-return-good-practices
I think using response 404 code is
Hi Peter,
Mac OS X 10.9.5 with Safari 7.1.2.
Thanks, I'll look into it.
The first time I clicked on the link it asked me for a certificate,
which seemed pointless to give it for API docs so I clicked Cancel.
Then it displayed the error.
Perhaps you can try the version without SSL?
On 19/01/2015 10:29, Diego Bosc? wrote:
I will just add that if you are making a server you probably want to
take a look and how FHIR does things. They have some pretty cool ideas
for common problems that you can probably reuse (e.g. using atom for
query responses)
Diego,
I think they are
I would agree with Isabel.
Not everything is a resource, or should be seen as a resource. If you
just want to pull back a lump of data, that could be a 'resource', and
for that a REST service based on FHIR or some other API will make sense.
Resource-oriented stateless services are suited to
Sad to see that go away, I liked the idea of reusing well known formats for
everything.
Regarding REST, I assume that nothing stops you to provide a method called
query with the actual AQL query as a parameter :D
2015-01-19 21:58 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com:
I
Ralph van Etten wrote:
Perhaps you can try the version without SSL?
http://mr.dev.medvision360.org/mr/apidocs/#!/
Yes, Ralph, that version works for me.
Also, for the record, Ralph made the server less strict so that the original
link that he gave us
I think you are comparing a not-so-good rest web service with a perfect
soap one. I.e. returning a 404 is wrong for 'method not found' (I have put
already the correct code in this same thread).
Lack of standard codes makes soap WS much more difficult IMHO.
El 17/1/2015 23:35, Bert Verhees
way :)
Pablo.
Sent from my LG Mobile-- Original message--From: Bert VerheesDate: Sat,
Jan 17, 2015 8:35 PMTo: openehr-technical at lists.openehr.org;Subject:Re: CRUD
Restlet.
There are good reasons for trying to reuse a few
--
*From: *Bert Verhees
*Date: *Sat, Jan 17, 2015 8:35 PM
*To: *openehr-technical at lists.openehr.org
javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');;
*Subject:*Re: CRUD Restlet
.
There are good reasons for trying to reuse a few standardized status codes
in HTTP if you
https://developers.google.com/drive/web/handle-errors
This is exactly my point, 404 is for handling errors, someone not being
in a hospital-register is not an error. To check if someone is, and he
isn't, that is not necessarily an error.
It may even be a good thing, that someone never has
Hi Bert!
Are you sure you have understood the difference between service orientation
and resource orientation? The background chapter in our paper I referred to
earlier briefly touches upon what a resource is, Fielding's dissertation
explains it in detail.
Why do you see the status 404 as an
On 18-01-15 11:32, Diego Bosc? wrote:
You are not asking for a person, you are asking the server for a
specific document about a patient that does not exist. A server can
have records with identifiers 111, 112, 113, etc. which can be about
the same patient or not. If you ask the server for
On 18-01-15 11:49, Erik Sundvall wrote:
Why do you see the status 404 as an evil error status but 200 as some
totally other kind of status?
Restlet has implemented 404 as an evil error: it means: if it cannot
route your URL, it returns 404.
So a client application has no useful information
For information:
See therecommendations by Ethan Cerami: Specialties: Cancer genomics,
bioinformatics, scientific computing, software engineering, project
management.
https://www.linkedin.com/in/ecerami
http://www.oreilly.com/pub/au/806
Read:
NP, but it is not a matter of opinion when there are conventions,
principles and guidelines. Of course it is your decision to not follow.
BTW, I've found that the Facebook API returns 200 even if there are app level
errors.
So I think this is a by-API decision. If you want to implement
:)
Sent from my LG Mobile
-- Original message--From: Bert VerheesDate: Sun, Jan 18, 2015 9:46
AMTo: openehr-technical at lists.openehr.org;Subject:Re: CRUD RestletFor
information:
See the recommendations by Ethan Cerami:Specialties: Cancer genomics,
bioinformatics
:)
Sent from my LG Mobile
-- Original message--
*From: *Bert Verhees
*Date: *Sun, Jan 18, 2015 9:46 AM
*To: *openehr-technical at lists.openehr.org
mailto:openehr-technical at lists.openehr.org;
*Subject:*Re: CRUD Restlet
For information:
See therecommendations by Ethan
, like the EHRScape ;)
--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
Date: Sun, 18 Jan 2015 20:41:35 +0100
From: bert.verh...@rosa.nl
To: pazospablo at hotmail.com; openehr-technical at lists.openehr.org
Subject: Re: CRUD Restlet
The point for me is separation
will not be able to use a lot of APIs that follow
principles and conventions you don't like, like the EHRScape ;)
--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com http://cabolabs.com/es/home
http://twitter.com/ppazos
Subject: Re: CRUD Restlet
The point for me is separation
Bert Verhees wrote:
The point for me is separation of transport layer and application layer, and
each domain has its own errorhandling.
Hi Bert,
HTTP is not a transport layer protocol:
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
?The Hypertext Transfer Protocol (HTTP) is an
--
*From: *Bert Verhees
*Date: *Fri, Jan 16, 2015 8:18 PM
*To: *For openEHR technical discussions;
*Subject:*CRUD Restlet
I was looking at EHRScape, I should have posted this question there, but
the Community-page does not show any communication-means, only adds.
And maybe the question is also
.
Sent from my LG Mobile
-- Original message--
*From: *Bert Verhees
*Date: *Fri, Jan 16, 2015 8:18 PM
*To: *For openEHR technical discussions;
*Subject:*CRUD Restlet
I was looking at EHRScape, I should have posted this question
On Sat, Jan 17, 2015 at 11:37:52AM +0100, Diego Bosc? wrote:
The thing is that as long as a code is returned, you know that the
server is up and has given you a response based on your request. By
the code you can tell you more things.
2xx messages tell you that the request was a success
4xx
Probably 405 'method not allowed' or just return a generic 400 'bad
request'. In either case you know it is your client fault.
Wikipedia is a good start for most common codes. You can see you can
cover a lot of use cases just with the codes on that page.
On 17-01-15 12:00, Diego Bosc? wrote:
Probably 405 'method not allowed' or just return a generic 400 'bad
request'. In either case you know it is your client fault.
Wikipedia is a good start for most common codes. You can see you can
cover a lot of use cases just with the codes on that page.
On 17-01-15 11:56, Karsten Hilbert wrote:
What would be the error code for when the client attempts to
call a non-existing service on the server ?
Sorry that I come back to this once more. Karsten almost gave a good
example, I want to explain my cause on a better but similar example.
The same
Hi Bert,
I think Diego emails are right on spot and can give you some hints about
RESTful principles.
Perhaps you should consider that, what you call 'service' is actually
the 'application' itself; than details about returned codes wont be that
weird anymore. Also, URLs are resource-refs
According to a discussion on StackOverflow, it should be allowed to use
HTTP-status to communicate application response.
There is a schema
http://i.stack.imgur.com/whhD1.png
Here is another (maybe better)
https://raw.githubusercontent.com/for-GET/http-decision-diagram/master/httpdd.png
The
.
There are good reasons for trying to reuse a few standardized status
codes in HTTP if you can (see Fieldings dissertation etc.) but the
codes are extensible if you really need to invent your own status code.
That is true, but Restlet already uses 404 for a method not found, or
an URL
58 matches
Mail list logo
