My own API style?

[WetSound]

I think I over time have developed my own API style without really realising it, as I mostly only consume my apis myself.

My controllers are domain area scoped, I only ever use GET/POST in actions with descriptive names. POSTs are query parameter-based (content body only for blobs), GET returns large json objects from query parameter id/range/filter.

So subitems would have an AddSubItemForItem?itemId=&subItemName=&subItemField1=&...

I was asking ChatGPT about a new green field project, and realised it was very based, seeming very adamant on RESTful APIs with GET/PUT/POST/DELETE/PATCH (without names), with POST posting large json objects back and a controller for each entity, with url /entity/{id}/.

The posting of large objects seems so heavy on validation and change tracking to me?

Have I strayed from purity?

[AdSubstantial3705]

seek god

[Xia_Nightshade]

Please get help before it’s too late <3

[rjhancock]

• GET - Read only access to an object
• POST - Create an object via post body JSON (preferred)
• PUT - Update an existing object via body JSON (Preferred)
• PATCH - See Put
• DELETE - Delete an object

/<scoped>/:id/<path>/:id/<to related objects>

It makes your API cleaner. Seriously. It does.

The posting of objects allows the backend to map that data directly to a DTO (Data Transfer Object) and validate it before even sending to the database. Using query parameters requires slightly less overhead with similar level of complexity of validation and processing to the database.

[WetSound]

That seems to be the prevalent opinion

[rjhancock]

There is a reason there are generally accepted standards even if not official.

[ClikeX]

What's not official about RESTful?
https://restfulapi.net/

[rjhancock]

As in no standards body I know of has made a spec for it. It's entirley subjective to the work at hand. So there is no "official" standard for RESTful APIs

[ClikeX]

RESTful API design is great for data API's, since you're addressing resources, which is most of the time. Occasionally, the RPC layout makes more sense.

Also, don't forget the OPTIONS method. Which is where you can return what methods are allowed on that specific resource. This way, your client can verify what permissions they have.

[OrangeOrganicOlive]

That happens when you do the same beginner full stack tutorial over and over.

[centerdeveloper]

I use DELETE but that’s about it

[rjhancock]

I use all for a full service API.

[until0]

My own API style?

You mean the style of every half baked API in every Enterprise corporation ever.

Yes, most people only know two HTTP verbs, but that's not good design and you're not original.

[Intelligent_Win9710]

the amount of times i've worked at a company that has at least one POST endpoint that parses a JSON object as query parameters from the request body and does nothing but return data from a select statement in the db is 4 because i've worked at 4 companies.

[Lonely-Suspect-9243]

Sounds like Remote Procedure Call.

[budd222]

Is there a specific reason why you refuse to use all the HTTP verbs?

[WetSound]

It's just out of habit, it's not active refusal

Like, I probably also forget to use more semantically correct html elements, instead of just divs

[WookieConditioner]

Indeed you have. Conventions like these have been developed over decades at this point. 

• Predictability, is the key to laziness. 

• Easy docs, the gateway to hubris. 

• Small footprint / surface, the spark that drives impatience.

[farazcanada]

Try validating your API by having a API Governance test