Designing Quality APIs (Cloud Next '18)

[@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

[@SiddharthKulkarniN]

Start at 5:00

[@DanDascalescu-dandv]

At 4:27 actually but yeah

[@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.

[@bocckoka]

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

[@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 )

[@mcnianliu]

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

[@parthibansrinivasan9182]

Love this talk by Martin Nally

[@almostrandomnickname]

Thanks very good talk !

[@antonpirhonen9698]

Good and clear talk! 👍

[@gatsdev]

I like this one

[@RamiiYoussef]

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

[@yashwanthnerella4031]

Good but boring and slow!