Operations that change data should not allow GET

[daliboz]

The book and hold operations currently document GET as an allowable option. However, you cannot use GET in HTTP to modify state on the server. High level overview of why this is bad: https://stackoverflow.com/questions/705782/why-shouldnt-data-be-modified-on-an-http-get-request

[Healthedata1]

Here is the FHIR Documentation regarding using Get for Operations and I think we meet all those criteria...

"When an operation is idempotent, and the parameters are all primitive data types with no extensions (as is the case with the example above), it may be invoked using GET as well."

I think Drew was arguing in favor of using GET. It is easier in that the input are simple and you do no have to refer to spec for determining what the elements are....

Let me know what you think?

Eric

Eric M Haas, DVM, MS Health eData Inc 211 South Jefferson Street, Napa, CA, 94559 707.227.2608|Skype: haas.eric1 ehaas@healthedatainc.com ehaas@healhtedatainc.com

On Tue, Aug 22, 2017 at 11:53 AM, Jenni Syed notifications@github.com wrote:

The book and hold operations currently document GET as an allowable option. However, you cannot use GET in HTTP to modify state on the server. High level overview of why this is bad: https://stackoverflow.com/ questions/705782/why-shouldnt-data-be-modified-on-an-http-get-request

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/argonautproject/scheduling/issues/32, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEU6qbqWoq8gKcit9TWuL-UkHm24c4Wks5sayOYgaJpZM4O_Cge .

[Healthedata1]

After today's we agreed that booking isn't Idempotent and could potentially book multiple times if the slots allowed overbooking. So will label as Idempotent and clarify that POST is the only method. Same for Hold too.

[Healthedata1]

applied