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

Comments

@JarJak
Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Nov 21, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 21, 2018

@JarJak

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

commented Nov 23, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 23, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.