apigoogle-app-enginerestgoogle-cloud-endpointsprotorpc

When to use. ProtoRPC or REST


I primarily deal with REST json APIs at my work. So I am familiar with them. But for my own project I am trying out app engine as I believe it is a great fit.

I had already started writing my logic in python (using ferris), and in reading more on app engine I came across protorpc and cloud endpoints. But in most of the examples I have read, they seem to be doing the same just as I would do in a rest api. Make a request with json, and get a json response back. Or an error.

The main difference I see, is that in rest, the endpoints are based around a resource. And the HTTP verbs around them such as GET, POST, PUT, DELETE, etc. Where as in RPC, each request would have it's own endpoint rather than be based around a resource or model.

Both are requested with, and respond with json. So I think I am failing to see the benefit of using Google endpoints. Do they offer some other kind of benefit? I could maybe see better analytics tracking with endpoints. But wouldn't I still need to the use post http verb for modifying content?

Would any of this change if I was using certain frameworks? Like django. Although I am currently testing out Ferris which has a messaging system that deals with protorpc. Although, I have not been able to rest or yet.

So what am I missing? What are the benefits of endpoints over just making my object methods handle a json request. Do socket connections play into this at all?


Solution

  • You can do both by using endpoints to make a RESTful API.

    protorpc/endpoints doesn't magically make your API RESTful. You have to make your API RESTful within the endpoints framework, which uses protorpc.

    The benefits of using endpoints is that you can get a lot of the authentication work done easily (assuming you're going to use Google accounts), the serialization/deserialization is done for you, your client libraries can be generated for you, and more than just a Javascript client can be supported. If these things sound good, endpoints may be right for you. If these things don't apply, then maybe be more direct and use RequestHandlers yourself.

    I was able to make a simple API using endpoints. It has 3 main resources: records, datasets and moves. A Record object is the smallest unit of data. The Dataset object is a group of records. And the Move object represents the event of a Dataset changing location. My RESTful URIs look like this:

    GET  /records       # Get list of records
    GET  /records/<id>  # Get single record
    POST /records       # Create records
    
    GET  /datasets      # Get list of datasets
    GET  /datasets/<id> # Get single dataset
    POST /datasets      # Create dataset
    
    GET  /moves         # Get list of moves
    GET  /moves/<id>    # Get single move
    POST /moves         # Create move
    

    With this I can create data, organize it and move it around. I was able to do this completely within the endpoints framework on App Engine and it is RESTful.