Re: REST-API: Show retired status

Hi Ralf:

In message <[email protected]>,
Ralf Schlatterbeck writes:
>On Sat, Mar 07, 2020 at 11:38:12AM -0500, John P. Rouillard wrote:
>> Your question does make me wonder if we need some way to query only
>> for retired items using the ../rest/data/<class> mechanism. Maybe to
>> support creating a table of retired items to unretire?
>
>The underlying API supports a retired parameter for some time now.
>So it's just exposing this in the REST API.

Yup. Maybe a query param for rest/data/<class>:

   @retired=True
   @retired=False (default if @retired is not specified)
   @retired=both

if True, only show retired elements

if False only show non-retired elements

if both, set retired=None in the underlying filter() API and all items:
retired and non-retired are shown.

I suggested True/False since @protected is a Boolean (true/anything
else) value. I think reusing the True/False semantics even though
@retired is a tri-valued logic value make sense.

I think the above is a useful addition.

How do you feel about using @retired with:

  rest/data/<class>/<id>?@retired=False

If the id is not retired, you get the same as:

  rest/data/<class>/<id>  (aka rest/data/<class>/<id>?@retired=both)

If the id is retired, you get some error code (204, 404).

As I write this up, this feels confusing. I wonder if adding the
retired state to the outer dict as you originally suggested is a
better way to do this. We don't have a use case that can be solved
only with this addition though. Maybe we defer this until we have a use
case that requires it so we don't overcomplicate this without cause.

Thoughts from anybody following along at home?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.