Different API response / a suggestion

[vlrmprjct]

Hello,

it would be great to have a restful API according some standards whit basic CRUD operations. What i mean is, there some different while fetching data.

For example: A list of parts gets a JSON response: https://part-db.herokuapp.com/de/category/17/parts

A single part get a HTML (Template) response: https://part-db.herokuapp.com/de/part/799/info

What the benefit:

• FrontEnd (JS) and BackEnd (PHP) are splitted ( maybe in two projects / repos ).
  • FE is using ReactJS, VueJS, Angular, or hardcore Plain JS or whatever ...
• ... for building some (Crossplattform) Applications

Anyway, it is a very nice project i am (long time) searching for. This is a suggestion only.

Have a nice day, Regards, Thomas

[jbtronics]

I am already planning an API for Part-DB. Because this new version is using symfony it should be really easy to implement REST and GraphQL APIs using API Platform (which also gives us things like automatic machine readible enpoint documentation)

My plan is to put the API endpoints under its own /api/ route, so the "normal" HTML pages and the real API are seperated. Also the API will most likely want to use other authentication possibilities (API tokens should be interesting for example), and it is much easier if we can but the whole API thing behind its own Symfony "firewall", which is easier if it is behind its own path.

In the moment I want to get Part-DB more feature complete, so I know better what features we have and how the models are connected, before implementing the API (I don't want to change the API each time I add some new features, which maybe need some deeper architecture changes).

About building a JS frontend: I have thought about it, but I don't have an experience with the Frontend Frameworks (and i did not want to learn to unknown things at once, Symfony AND a frontend framework).

Maybe we can build a real SPA frontend later (when we have an stable API), in the moment I will continue using Twig for rendering on server side.

[vlrmprjct]

Thank you for your quick response! Sounds good. GraphQL is a bit overengineered in my opinion, unless this application runs as a (multiuser) cloud service.

( ... and yes, if I had enough time I would start with a ReactJS FE using current API implementation )

Thank your for your hard work and this this application!

[jbtronics]

There is an API available for some time. So this issue is resolved.