If options are children of products and not many-to-many then the only logical way to have two endpoints in the API is if the parent (Aggregate root in DDD speak) items are readable/writable as a consistent tree, while the query for child items in /api/options is a read only api.
There is nothing nonstandard about such a REST api. If a product must be associated with an option then the /product/create endpoint should only accept a product with an option already attached.
> This kind of “pure” rest api is simply convenient to the developer because they push the problem of object consistency to the client.
It's not like REST means that to be "pure" or "standard" you end up exposing all your database tables with read/write and just let callers CRUD anything they want, including creating inconsistent data?
> “the rules” of rest APIs.
The rules are very simple: the REST api should expose and enforce the consistency rules of the business logic!
There is nothing nonstandard about such a REST api. If a product must be associated with an option then the /product/create endpoint should only accept a product with an option already attached.
> This kind of “pure” rest api is simply convenient to the developer because they push the problem of object consistency to the client.
It's not like REST means that to be "pure" or "standard" you end up exposing all your database tables with read/write and just let callers CRUD anything they want, including creating inconsistent data?
> “the rules” of rest APIs.
The rules are very simple: the REST api should expose and enforce the consistency rules of the business logic!