Designing Quality APIs (Cloud Next '18)

A quality API has to satisfy demands of ease of use, ease of learning, stability in the face of change, and compatibility with client tools and technologies. Adding to the challenge is the fact that there are two irreconcilable conceptual models for API designs - RPC and REST. Come and learn how to think about the RPC/REST dichotomy and understand the problems and solutions of quality API design-regardless of the model chosen. We will also present some of the major GCP services and tools that are used to implement APIs in both models.
DEV230
Event schedule → g.co/next18
Watch more Application Development sessions here → bit.ly/2zMcTJc
Next ‘18 All Sessions playlist → bit.ly/Allsessions
Subscribe to the Google Cloud channel! → bit.ly/NextSub
re_ty: Publish; product: Cloud - General; fullname: Martin Nally; event: Google Cloud Next 2018;

[@DanDascalescu-dandv]

Highlights:
* 16:49 - include the path in the id
* 20:15 - use a URL instead of the id
* 27:30 - best practices / implementation bias
* 29:06 - indexed collection bias

[@krtirtho]

Would have liked more if GraphQL APIs were also discussed along side REST & RPC. Moreover, nice explanation... Thanks

[@bhaveshtiwari5783]

I think it is more valuable for front frontend and this talk is more about backend

[@LogicPhalanx]

I think you can consider GraphQL to be an entity-oriented API.

[@IgorDonin]

I wouldn't say it's entity-oriented but for sure it would need a shared model. But for me it looks more like RPC. You have a fixed endpoint - like /graphql - and then you have a lot of autonomy as long as you know the data model.

[@jahmanichauvet360]

This was a good place for me to start

[@lhxperimental]

I use JAX-RS to automatically Marshal and unmarsahl JSON into Java objects. Having a string like "/pet/12345" as ID instead of just 12345 would mean the parses won't work. or I will have to create an additional property in every entity to hold the string value and then extract the integer ID in post processing. Same for the other direction. Plus I probably have to name the string version of ID as id and the native integer id as int_Id or _id. So the string hack takes up the proper name "id" and the actual integer ID gets a second class name. The clean flow from database to JSON using generic code is also disturbed. Any suggestions?

[@mihu86]

Your JAX-RS implementation has to have a marshaller which does the convertion and it's usually well configurable. Suppose Jersey with Jackson. Then you can configure the marshaller to use only your getters/setters (actually this is the default for Jackson). So even if you have a "long" id (as a private field) you just have to provide a String getter for it. Or you can use custom serializers.
But by the way you may rethink your design altogether based on the statement at 13:16 - decoupling your rest domain from your data access layer. (And this can even be somewhat automated with e.g. Spring Data REST - despite that at first sight it seems that it just exposes your persistent entities: www.infoq.com/presentations/ddd-rest/#anch142195 )

[@parthibansrinivasan9182]

Love this talk by Martin Nally

[@antonpirhonen9698]

Good and clear talk! 👍

[@almostrandomnickname]

Thanks very good talk !

[@mcnianliu]

This is mind blower. Actually helps a lot of stuff I am working on. Does anyone happen to have those slides?

[@bocckoka]

entity oriented and procedure oriented maps to OO and functional it seems

[@gatsdev]

I like this one

[@SiddharthKulkarniN]

Start at 5:00

[@DanDascalescu-dandv]

At 4:27 actually but yeah

[@RamiiYoussef]

Very bad ideas, i'm shocked you are in google cloud.

[@yashwanthnerella4031]

Good but boring and slow!