CRUD Restlet

+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 h

CRUD Restlet

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 i

CRUD Restlet

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,

CRUD Restlet

On 18-01-15 11:49, Erik Sundvall wrote: > 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.

CRUD Restlet

://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

CRUD Restlet

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 2015

CRUD Restlet

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

CRUD Restlet

Restful webservice is widely used in all kinds of companies in China. especially when the mobile health or mobile internet technology flood all over the wolrd .but there is a thing we should notice these use cases are all in the information exchange or work flow creation inside one company or e

CRUD Restlet

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

CRUD Restlet

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 simp

CRUD Restlet

I have already done that ;) When MIE accepts the paper I can tell more :D 2015-01-19 22:08 GMT+01:00 Thomas Beale : > On 19/01/2015 21:01, Diego Bosc? wrote: > > Sad to see that go away, I liked the idea of reusing well known formats for > everything. > Regarding REST, I assume that nothing stops

CRUD Restlet

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 : > > I would agree with Isabel. > > Not e

CRUD Restlet

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 http://mr.dev.medvision360.org/mr/api

CRUD Restlet

On 19/01/2015 21:01, Diego Bosc? wrote: > 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 sure - but that forces the app pr

CRUD Restlet

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 so

CRUD Restlet

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 a

CRUD Restlet

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? htt

CRUD Restlet

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 talk

CRUD Restlet

Sorry, I know that this is not the list to have this discussion but the sentence "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!! Sta

CRUD Restlet

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 re

CRUD Restlet

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/ap

CRUD Restlet

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

CRUD Restlet

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 r

CRUD Restlet

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

CRUD Restlet

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

CRUD Restlet

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 wa

CRUD Restlet

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 > >> On 19 jan. 2015, at 11:29, Diego Bosc? > > wrote: >> >> I

CRUD Restlet

Niet een slecht advies: Kijken bij FHIR van HL7 GF Gerard Freriks +31 620347088 gfrer at luna.nl > On 19 jan. 2015, at 11: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 s

CRUD Restlet

One thing I always felt that openEHR needed was something like a connectathon. I think we have currently a sufficient number of companies and developers involved to start this. 2015-01-19 11:44 GMT+01:00 Ian McNicoll : > Hi all, > > I agree with Diego -stay close to FHIR, if only because it will r

CRUD Restlet

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

CRUD Restlet

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 : > I've managed not to respond

CRUD Restlet

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 g

CRUD Restlet

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

CRUD Restlet

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 U

CRUD Restlet

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 parti

CRUD Restlet

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 wor

CRUD Restlet

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 no

CRUD Restlet

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 o

CRUD Restlet

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 het volgende g

CRUD Restlet

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

CRUD Restlet

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 driv

CRUD Restlet

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 appl

CRUD Restlet

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

CRUD Restlet

404 means in each case and has the correct urls for every resource :) > > > > 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 > <mailt

CRUD Restlet

:) 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

CRUD Restlet

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

CRUD Restlet

like, 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 separati

CRUD Restlet

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: http://archive.oreilly.com/pub/post/restful_error_ha

CRUD Restlet

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 fr

CRUD Restlet

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

CRUD Restlet

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 evil

CRUD Restlet

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 a inexistent document identifier it gives you

CRUD Restlet

> 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 b

CRUD Restlet

line, it is no good or bad, it is the REST way :) > > > > Pablo. > > > Sent from my LG Mobile > > -- Original message-- > > *From: *Bert Verhees > > *Date: *Sat, Jan 17, 2015 8:35 PM > > *To: *openehr-technical at lists.openehr.org > ; > &g

CRUD Restlet

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" escrib

CRUD Restlet

od or bad, it is the REST 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 t

CRUD Restlet

. > > 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 UR

CRUD Restlet

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 disc

CRUD Restlet

Hi! Some more thoughts regarding specific questions: On Sat, Jan 17, 2015 at 6:20 PM, Bert Verhees wrote: > > Another reason why it is wrong to misuse the HTTP-status for communicating > application errors is that there can be only one HTTP-status, and an > application may want to communicate mo

CRUD Restlet

Hi! I agree with others here that what Bert is seeing (but perhaps not liking) is most likely proper REST behaviour. HTTP/REST was designed to work a certain way on purpose for particular reasons that can all be found in the (very readable and well explained) dissertation of Roy Fielding, http://

CRUD Restlet

Thanks Sebastian for your reply. I have spotted some REST-implementations which use the HTTP-status to communicate application-circumstances. They are mixing the network-layer (HTTP) with the application layer. It is a very old principle and I learned to not do this. I explained why, below. H

CRUD Restlet

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 rathe

CRUD Restlet

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 sam

CRUD Restlet

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

CRUD Restlet

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. http://en.wikipedia.org/wiki/List_of_HTTP_st

CRUD Restlet

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 >

CRUD Restlet

There are specific errors to wrong method calls, unsupported mime, etc. As long as the server returns the correct code then there won't be interpretation errors. 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 t

CRUD Restlet

of the HTTP infrastructure, like methods, status codes, sone > headers, etc. > > > Sent from my LG Mobile > > -- Original message-- > > *From: *Bert Verhees > > *Date: *Fri, Jan 16, 2015 8:18 PM > > *To: *For openEHR technical discussi

CRUD Restlet

> -- 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 there, but > the Community-page doe

CRUD Restlet

Hi Bert, that's a REST Web Services convention. REST reuses a lot of the HTTP infrastructure, like methods, status codes, sone headers, etc. Sent from my LG Mobile -- Original message--From: Bert VerheesDate: Fri, Jan 16, 2015 8:18 PMTo: For openEHR technical discussions

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 generic and are more people thinking about this. I am wondering about the HTTP-errors, they seem to be used for communica