I have to design a small web-based application (flask, MySQL) and it will also need an API (e.g. JSON).

Is it good/recommended practice to have the web browser directly use the JSON API? Or should I just let it post form data and reuse the underlying business logic?

A JSON api should use, well... JSON. So yes, your form should post to a json endpoint.

Edit: requires you to use fetch/XMLHttpRequest or whatever it's called.

@olback Would you say a JSON API has to be RESTful to be considered a "good" JSON API?

Your API being a JSON API and a RESTful API are two separate matters to decide on

If you don't need to hide your api endpoint, use frontend post.

If you need to hide your api endpoint: backend post.

That's really all it comes down to.

What you send the api could be anything from json, xml, binary, some encrypted blob, or something else, it's really up to the api in question to dictate what it can and can't accept.

Json is just a textual representation of the data, the api being "restful" is its own problem.

you should never directly call the database to the open web.
You may want to have a look at graphql it makes it easy to access your data.

www.graphql.com

https://bcb.github.io/python/...
GraphQL in Python with Flask

@BobbyTables

Some are pointing you in maybe the right direction... But maybe not.

Let me ask u a question instead: What do you want to achieve?

@HCC5GDKc7 I think I've been indoctrinated by REST that anytime I work with a JSON API I automatically assume REST. So I completely agree with you.

@IntrusionCM (This is greatly simplified but roughly...) Web page to enter in requests, edit requests, claim requests, mark requests complete. All this is tracked in DB. Also need this to have an API for automation of managing said requests.

@BobbyTables

Okidokili.

I find it easier to explain it without the usual shenanigans (buzzword bingo).

Requests seem pretty simple, as the need for stuff beyond CRUD should be minimal (complex search, stats, aggregating, ...)

As such, an REST API for CRUD should be a good start.

JSON as data format due to JavaScript / web frontend is obvious.

That's the public API - handling CRUD.

Internal stuff depends on the cost / usage, eg regarding database:

You can create a database agnostic software (high cost) or just depend on MySQL (lower cost).

FLASK as an ORM has some abstraction, but being (truely) database agnostic would require more Work (eg adapter for the different database systems, additional layer for abstraction between database adapter - business logic).

Thus... Draw an onion.

Outer skin is the public API, possible consumer is a user or an automation / testing system.

Inner layers: What libraries do you use for which task? How do they interact? Is there a need for seperation / abstraction?

Core: The services you use - eg. a database, maybe an public API as Google Maps, maybe Pornhub ;)

Drawing the onion might sound stupid, but it's easier than drawing a complex UML / whatever diagram...

I just want to emphasize that using a JSON Api doesn't equate to having a REST Api or that you have to make it restful since I came across this misconception a lot with former colleagues and class mates