Open
Description
At this moment we have get
verb that accepts a SELECT
query. Some endpoints return a single object (GET /category/1
) while others return a list (GET /categories
). In addition, when we expect an object, code should return 404 error for an empty result, while for a list, it should return an empty list. Example:
- path: /categories/:id
get: SELECT id,name FROM categories WHERE id = :id
- path: /categories
get: SELECT id,name FROM categories
How we can distinguish such cases so we can generate different code?
Metadata
Metadata
Assignees
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
[-]How to distinguish controllers that return a single object or a list?[/-][+]How to distinguish controllers that return an object or a list?[/+]php-coder commentedon Jul 15, 2020
Option 1: use rules for guessing what is expected to be returned
For example,
SELECT COUNT(*) FROM ...
will always return a single object (as well as usage of other aggregated functions. If a query hasLIMIT 1
orWHERE id = :id
it also returns a single row.Pros:
Cons:
id
field isn't unique or what if my query hasWHERE slug = ?
andslug
field is unique but we don't take it into account)php-coder commentedon Jul 15, 2020
Option 2: let user to specify what is expected in the result
The name also could be
return_type: object|list
,single_result: true|false
,list: true|false
,return_one: true|false
The name also could be
returns:list
,multiple_results
, etcget_list
in addition toget
:Here we have many names:
get
/get_many
orget_one
/get_many
orget_one
/get_list
orfind_one
/find_many
.Pros:
get_list
is short enoughCons:
find_*
)theshamuel commentedon Jul 17, 2020
Hey @php-coder, I suppose, that option 2.1 is more suitable for fixing your issue. Because but no matter as you wish you cannot avoid adding new field, so it had better been more clear for understanding for user. That is why modify
get_
and creating one commonhints
looks a little bit weird for me. If you use fieldreturn: list/object
I think it is really obvious what for it.feat: add get_list verb to support GET with a list of objects
php-coder commentedon Jul 22, 2020
After discussions I started to think about introducing a single field. I had something like this in mind:
Because I can't predict future and I can't suggest an option that I would be happy with, I've decided to go with the simplest and fastest approach right now. I will change API when I have more use-cases. In 44c061d I introduced
get_list
verb.I leave the issue open because I anticipate that the current solution will be revised in future.