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 a client for an
API, you should follow the rules defined by that API.
Cheers,Pablo.
------ Original message------From: Bert VerheesDate: Sun, Jan 18, 2015 6:22
AMTo: pazospablo at hotmail.com;Cc: openehr-technical at
lists.openehr.org;Subject:Re: CRUD Restletthanks,?Pablo.
Since Rest is not a standard, it is a matter of agreeing or not. I'm not sure
how to proceed. It is not that having it one way or the other is a lot of work
to implement. It is just, what seems better. I was often stubborn,
Rowing?against the general opinion was?often to my advantage. I will think it
over.?
I wish to thank?you all for the discussion and the info.
Best regardsBert.
Op zondag 18 januari 2015 heeft pazospablo at hotmail.com <pazospablo at
hotmail.com> het volgende geschreven:
Hi Bert, this is not really a matter of agreeing or not, or if it's
good or bad reusing http status codes: is the way REST services work. If you
don't like it, you should use SOAP.
Every REST API out there uses status codes for app info, twitter, google, ....
https://dev.twitter.com/overview/api/response-codes
https://developers.google.com/drive/web/handle-errors
This is a really nice guide I use a lot, it helped me to understand the "REST
way" of doing
things?http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
Bottom line, it is no good or bad, it is the REST way :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/285d266a/attachment.html>
