In the application I am currently working on, there are generally 3 types of HTTP calls:

  • pure GETs
  • pure POSTs (updating the model with new data)
  • "GET" POSTs (posting down an object to get some data back, no updates to the model)

In the integration service, generally we name methods that post "postSomething()", and methods that get, "getSomething()".

So my question is, if we have a "GET" POST, should the method be called:

  • getSomething - seeing as the purpose is to obtain data
  • postSomething - since we are technically using POST
  • performSomeAction - arbitrary name that's more relevant to the action

What are everyone's thoughts?

closed as primarily opinion-based by gnat, GlenH7, Bart van Ingen Schenau, user40980, Thomas Owens Jan 26 '14 at 9:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


I would not tie my method names to the HTTP operation they perform at all but with the semantics/business logic they offer.

Consider that the HTTP API you are using may change, which would impose that you go through your client code-base and update everything from "getXyzEntity" to "postXyzEntity" or "updateXyzEntity" or whatever.

If you implement these functions in a class hierarchy that is used all over your code base, you will end up having to update lots of client code for what is essentially an implementation detail.

I would call all my methods depending on what I wanted the client of the code to see (i.e. "client code wants to update Xyz Entity and should not care if that is implemented in terms of a HTTP GET, POST or that it even performs a HTTP call for that).

'getSomething` is OK for getting data from the server, but it should have nothing to do with it being implemented through a HTTP get, and everything with the it "getting data" and returning it to the client.

  • Makes sense. I was thinking along the same lines - if it's a pure server request, I think it makes sense to name it for what it is. If it's higher level than that, descriptive names are the best. Thanks! – antonpug Nov 4 '13 at 13:31
  • This is also a good solution (name methods for their semantics, not internals) because you may change the implementation completely. For example, you could add an internal cache (HTTP or otherwise), that will get you the data without connecting the server at all. If you implement such caching transparently to client code, the method name should not change with the addition of caching. – utnapistim Nov 4 '13 at 13:33

I would use requestSomething. It is different than get and post, and is what you actually want to do.

Not the answer you're looking for? Browse other questions tagged or ask your own question.