Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Content API endpoints for Frontend #150

Closed
JarJak opened this issue Nov 20, 2018 · 5 comments
Closed

Create Content API endpoints for Frontend #150

JarJak opened this issue Nov 20, 2018 · 5 comments
Labels
needs splitting Issue is too big: Needs to be split up into several smaller issues topic: API All issues dealing with API-Platform
Milestone

Comments

@JarJak
Copy link
Member

JarJak commented Nov 20, 2018

GET single and GET multiple, with sorting, search etc.
Can be tricky due to new Content - Field (EAV?) relation.
Hydra annotations should be added too.

@JarJak JarJak changed the title Create Content API endpoints Create Content API endpoints for Frontend Nov 20, 2018
@bobdenotter
Copy link
Member

Is this different from what we already have listed in /api? If so, and it's considered useful to have, i'd be in favor of adding it..

I believe @jackiboy also had an opinion on GraphQL and/or Hydra. Let's discuss on how to proceed with this. :-)

@bobdenotter bobdenotter added this to the Bolt 4.0.0 beta 1 milestone Nov 21, 2018
@bobdenotter
Copy link
Member

@JarJak
Copy link
Member Author

JarJak commented Nov 22, 2018

@bobdenotter yes it is different:

  1. in frontend we need only GET endpoints (+ POST for preview and boltforms extension, but only for those)
  2. /fields endpoint doesn't make sense IMO
  3. /content should return data the same way setcontent does (actually setcontent could use API Models internally), so:
  • contents with fields with data
  • paging
  • sorting
  • filtering
  • searching
  • returnsingle
  • relations (bidirectional too)
  • etc.
  1. additionally /me endpoint would be nice (returning current logged in user)

We will need Content Serializer OR Read Model and Transformer for that.

Another thing is that IMO if we do headless AND traditional frontend, all API endpoints should be prefixed with /api

@bobdenotter
Copy link
Member

I know @nestordedios already did some work on this.. We can use the API to fetch Records, with all its Fields.. @nestordedios, maybe you can chime in?

Futhermore, we might need POST (or PUT) endpoints for Fields. The main edit interface will be traditional server-request-response type interaction, but Jack made a start on the interface for "quick edit", so there it'd make sense if you could update a specific field like "title" or "status".

Another thing is that IMO if we do headless AND traditional frontend, all API endpoints should be prefixed with /api

Sure.. Perhaps even /bolt/api/?

@nestordedios
Copy link
Collaborator

@JarJak I'm not very familiar with API Platform yet and there are indeed points to improve.

  1. /fields endpoint doesn't make sense IMO

The reason I added the Fields entity to the Model is because the Content Entity has a collection of Fields Entities, and by not adding them to the Model the fields where not fetched in api/contents/{id} How to get that endpoint working without exposing api/fields in the API I haven't managed.

@JarJak JarJak added the topic: API All issues dealing with API-Platform label Dec 1, 2018
@JarJak JarJak added the needs splitting Issue is too big: Needs to be split up into several smaller issues label Feb 7, 2019
@JarJak JarJak modified the milestone: Bolt 4 alpha 3 Feb 7, 2019
@JarJak JarJak closed this as completed Apr 14, 2019
@JarJak JarJak mentioned this issue Apr 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs splitting Issue is too big: Needs to be split up into several smaller issues topic: API All issues dealing with API-Platform
Projects
None yet
Development

No branches or pull requests

3 participants