ign patterns. :-)
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part ------
An HT
Best regards and have a nice day.
>> Bert
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>&
--
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/f41ec4c2/attachment.html>
_
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/6d829489/attachment-0001.html>
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
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
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
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
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
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
>
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
> openEHR-technical at lists.openehr.org
> <mailto:openEHR-technical at lists.openehr.org>
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/6b659678/attachment-0001.html>
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/7a890941/attachment.html>
t and
error-message on application level.
Someone thoughts about this?
Thanks
Bert
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/
14 matches
Mail list logo