Plan REST API for 3.0
Primarily due to the search API being tied to mongodb, and that pulp 3.0 will not use mongodb, pulp 3.0 will require a new API for search. Search is pervasive throughout the REST API, so a huge number of endpoints will have to change.
While we're at it, there are a number of API changes that have been desired for some time, and this will be a rare opportunity to act on them.
Ideally we will be able to auto-generate most or all of the API and its docs.
#9 Updated by semyers over 3 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to semyers
Because of issues with the translation of search queries, Katello recorded this list of all the criteria searches that Runcible uses. This should be helpful in determining their search requirements.
I believe that most of the "search" views in pulp 2 will be managed with normal filtering in pulp 3. DRF integrates with django-filter0, and exposes a pretty robust filtering mechanism via REST URLs, so we should pull out some characteristic searches that Katello is doing and looking at how we might construct Django queries or django-filter queries based on them.
I thought I added checklist items to better represent this task; I'll correct that in a moment. In the meantime, I'll point out that implementing the functionality provided by Pulp 2 "search" is likely going to be the least difficult piece of the pulp 3 API to figure out. Coming up with a reasonable implementation to handle our master/detail relationships is likely going to require some serious thought and effort. I've done some initial work on this in the rel-pulp project, so I'd like to take this on and continue that effort.
#10 Updated by semyers over 3 years ago
- Checklist item Lay out initial documentation for properly documenting API endpoints added
- Checklist item Figure out how to compile endpoint documentation into a single document using DRF's features added
- Checklist item Based on search requirements, identify model fields that we'll want to expose as filterable added
- Checklist item Put together a demo of DRF's autogenerated API client added
Checklist updated. :)
#12 Updated by email@example.com about 3 years ago
- Checklist item Identify search requirements from stakeholders set to Done
From the requests from katello tests, I have concluded that we will not need to implement full text search, that filtering is enough. Given that modeling is still going on, we cannot "identify model fields that we'll want to expose as filterable" because those fields might not exist or might change.
https://github.com/pulp/pulp/pull/2740/ implements and explains one of each type of filter. This demonstrates that filtering is powerful enough to meet katello needs and is as complete as we can get without finishing modeling first. Once modeling is complete, it will be necessary to re-review the requests on this ticket and ensure that the appropriate fields are filterable to allow comparable filters.
#14 Updated by semyers about 3 years ago
- Checklist item Lay out initial documentation for properly documenting API endpoints set to Done
- Checklist item Figure out how to compile endpoint documentation into a single document using DRF's features set to Done
- Checklist item Based on search requirements, identify model fields that we'll want to expose as filterable set to Done
- Checklist item Put together a demo of DRF's autogenerated API client set to Done
#15 Updated by semyers about 3 years ago
I've been hacking on this branch for a while now, and there are a lot of ideas captured on it that aren't related to this issue directly. I've already broken out and created PRs for a few of these, and will continue to do that until that branch is focused on just this issue. At that point,
I'll come back to the docs with fresh eyes to clean up errors and inconsistencies and open the PR to get to POST for feedback.
Please register to edit this issue