Conscious about REST? Then you want to have control over HTTP methods associated with your API calls. Should you choose not to use @ApiMethod, Endpoints falls back to an educated guess approach based on the API method name, as stated in the docs. I couldn’t find much details about how the resolution works, but common sense worked for me. This post presents my findings when experimenting with automatic HTTP method resolution.
The educated guess approach proved to work well. Please find below a summary of the naming conventions I found working reliably. The code examples are based on the official tutorial.
GET
Method name starts with get or list
[java]
public HelloGreeting getGreeting(@Named(“id”) Integer id) {..}
GET http://localhost:8080/_ah/api/helloworld/v1/hellogreeting/0
public ArrayList<HelloGreeting> listGreeting() {..}
GET http://localhost:8080/_ah/api/helloworld/v1/hellogreeting
[/java]
POST
There are no special conventions. POST is a fallback in case the method won’t resolve to either GET or DELETE.
DELETE
Method name starts with remove or delete
[java]
public ArrayList<HelloGreeting>
removeGreeting(@Named(“id”) Integer id) {..}
DELETE http://localhost:8080/_ah/api/helloworld/v1/greeting/0
public ArrayList<HelloGreeting>
deleteGreeting(@Named(“id”) Integer id) {..}
DELETE http://localhost:8080/_ah/api/helloworld/v1/greeting/0
[/java]
PUT
As far as I can tell it is impossible to get to a PUT method without using @ApiMethod.
[java]
@ApiMethod(name = “greetings.put”, httpMethod = “put”)
public ArrayList<HelloGreeting>
putGreeting(@Named(“id”) Integer id,
@Named(“message”) String message) {..}
PUT http://localhost:8080/_ah/api/helloworld/v1/putGreeting/0/hi%20there
[/java]
This post is part of Google App Engine and Android – Pros and Cons, Challenges
