Sometime back I developed a Restful service in Java with only 1 GET resource. It was accessed like this:
GET http://localhost:8080/my-project/customers/transactions
This GET request returns all the customer transactions.
Now, I have another project request where they want to insert customer transactions in a different schema in same database. I thought instead of creating other service I could enhance this service since underlying database is same and it's about customer transactions.
So, I created another method in my service interface createCustomerTransactions and I am thinking to name it same as my GET request but this one will be POST like this:
POST http://localhost:8080/my-project/customers/transactions
I tested this using Soap-UI and it works. My question is it the right way to do Restful. Is it okay to have both GET and POST having same url, internally though they will be pointing to different actual methods? I am not good with names so can't come up another better name for resource.
TL;DR Yes you can, it is actually a good practice.
Here is why:
Restful when is used with HTTP depends in the resources(URL's) and rely the actions the HTTP verbs, it is common and good practice used this verbs to identify some operations over the resources you have:
GET retrieve all or just one resource.
POST is normally for create a new resource.
PUT used to update a resource
DELETE delete a resource
One of the first tasks that we should do before starting our Restful API is identify which are the resources that we need to have and what will be the attributes of them. The first rule over this approach is to use nouns not verbs, such as person, ticket, customer , etc..
Once you have your resources defined, you need to identify what actions apply to them and how those would map to your API. RESTful principles provide strategies to handle CRUD actions using HTTP methods mapped as follows.
GET /tickets - Retrieves a list of tickets
GET /tickets/12 - Retrieves a specific ticket
POST /tickets - Creates a new ticket
PUT /tickets/12 - Updates ticket #12
PATCH /tickets/12 - Partially updates ticket #12 <-- check this approach.
DELETE /tickets/12 - Deletes ticket #12
The above depends on firewall configurations, but consider the above as a suggestion for API design principles.