Using @POST instead of @ GET in REST API?


The typical @POST format in a REST API is like (I am writing for Kotlin):

@POST("users")  
suspend fun addpost( @Body post:Post) : Post   

After posting, I can just fetch that same data, or even list of data, through only @POST, i.e. in a modern day app login system where their first user would be added then fetched can be done by just @POST. Then why would I use @GET in this context?

I know that if you only rely on @POST to create and then immediately return the full list, that's technically possible, but it's not idiomatic REST. It mixes two responsibilities in one endpoint.

But, what I have is only one endpoint in the backend named user and just used that for above context, and all coders accessing the code would be told about the usage of only @POST prior so that they also follow the same. Thus no confusion.

What is the actual benefit of using @GET in this context, instead of just that it is REST protocol to use both, etc.

I just want a solid reason why not use only @POST for the above context in all my apps?

0
Mar 6 at 10:02 PM
User AvatarRabinarayan Barik
#android#kotlin#rest

Accepted Answer

The way I am reading you question is as you endpoint is having two meanings. POST= to create a user. POST= to read a user. Just this makes confusion. Would it not be easier to say POST= create and GET = read. This is just basic semantics but thats what makes coding so much more beautiful compared to unclear language :)

User AvatarPatrik Rikama-Hinnenberg
Mar 6 at 10:23 PM
1