ATHENA 1.0 behavior for PUT getting changed in 1.1

2 views
Skip to first unread message

Gary Moore

unread,
May 9, 2011, 9:21:00 PM5/9/11
to athena-t...@googlegroups.com
Guys,

Updating a ticket in ATHENA using a PUT would not delete props that weren't sent. For example, if a ticket looked like this:

{"id":"4","price":"40","section":"A"}

and you issued a PUT /tickets/4
{"id":"4","price":"50"}

The resulting ticket would look like:

{"id":"4","price":"50","section":"A"}

Notice that "Section" remains even though it wasn't sent in the PUT

I never liked this, and I'd like to change it because it would more closely adhere to the HTTP PUT spec and make life with eligibleSellers much easier. The future:

{"id":"4","price":"40","section":"A"}

and you issued a PUT
PUT /tickets/4
{"id":"4","price":"50"}

The resulting ticket would look like:

{"id":"4","price":"50"}

Notice "section" went away because it wasn't sent.

On a practical level:

- every client (that I know of) sends the whole object on every request. So, nothing will change for them.
- The patch endpoint (just added to 1.1) allows clients to send a part of record that is applied as an update to one or more records. So, any clients that depend on the old way can still function as long as they point to /tickets/patch/{ids}

Any objections?

Gary

--
Gary Moore | gary....@fracturedatlas.org | @gsmoore
Fork us on Github: http://github.com/fracturedatlas/
Join us on IRC: ##athena on irc.freenode.net

Stjepan Rajko

unread,
May 9, 2011, 9:38:10 PM5/9/11
to athena-t...@googlegroups.com
On Mon, May 9, 2011 at 6:21 PM, Gary Moore <gary....@fracturedatlas.org> wrote:
- The patch endpoint (just added to 1.1) allows clients to send a part of record that is applied as an update to one or more records.  So, any clients that depend on the old way can still function as long as they point to /tickets/patch/{ids}
 
Any objections?


No objections :-)  But in most APIs I've seen the way to update a record (while keeping unspecified fields unchanged) would be to POST to the resource.  E.g., if a ticket looked like this:

{"id":"4","price":"40","section":"A"}

and you issued a POST /tickets/4

{"id":"4","price":"50"}

The resulting ticket would look like:

{"id":"4","price":"50","section":"A"}

(copy/paste of your original PUT behavior).

So maybe using a POST instead of the patch endpoint would be more conventional, though maybe you have other reasons for the patch endpoint.

Best,

Stjepan


Reply all
Reply to author
Forward
0 new messages