Best practices in web API client development #RubyKaigi

Transcript

1. Best practices in web API client development RubyKaigi 2019 /

   #rubykaigi #rubykaigiD pixiv Inc. sue445 2019.4.20

2. Hello! 2

3. My name is Go 3

4. 4 About sue445 • Name: Go Sueyoshi ◦ Go =

   剛 = strong • a.k.a. sue445 ◦ https://twitter.com/sue445 ◦ https://github.com/sue445 sue445

5. 5 About sue445 • Birthday: 1982/04/07 ◦ Last week was

   my birthday ◦ age 36 -> 37 sue445

6. 6 Experience • Ruby: 7 years • Golang: 4 years

   • Go: 37 years (age) sue445

7. 7 About sue445 • Birthplace: Fukuoka ◦ School days ◦

   〜 age 26 • Currently at: Tokyo ◦ pixiv Inc. sue445

8. 8 About sue445 • Community ◦ Shibuya.rb ◦ Omotesando.rb ◦

   Shinjuku.rb ◦ Meguro.rb ◦ etc sue445

9. 9 About sue445 • RubyKaja 2014 ◦ http://kaja.rubyist.net/2014/kaja ◦ https://www.slideshare.net/tyabe/ruby-kaja2014

   sue445

10. • https://rubygems.org/profiles/sue445 ◦ e.g. rubicure (Ruby implementation of Pretty Cure)

    ▪ https://github.com/sue445/rubicure ◦ Maintainer of Itamae and chatwork-ruby 10 Gems I developed

11. 11 About pixiv Inc.

12. MAKE CREATIVITIES MORE ENJOYABLE 12 About pixiv Inc.

13. • https://www.pixiv.co.jp/ • Place: Tokyo and Fukuoka • Silver Sponsor

    13 About pixiv Inc.

14. 14 FAQ. Is pixiv Inc.’s main lang PHP?

15. • Ruby is widely used at pixiv Inc, too 15

    FAQ. Is pixiv Inc.’s main lang PHP?

16. 16 What I've been doing at pixiv Inc.

17. • SUE (sue445) sounds like SRE (Site Reliability Engineer) ◦

    My job is almost like that of an SRE ▪ e.g. web application, library, infra, CI etc ... ◦ Ansible >>>> Terraform >>> Ruby ▪ BTW. I’m an Itamae maintainer 17 What I've been doing at pixiv Inc.

18. • https://rubykaigi.org/2019/presentations/ota42y.html#apr18 • @ota42y was my colleague • I was

    his mentor when he was an intern (2012/08) 18 Me and @ota42y

19. • OpenAPI3 is Bright side of API 　　 (IMO :-P)

    ◦ There is a shining future • My talk is about Dark side of API ◦ Fight against reality 19 　 Bright side vs Dark side of API

20. • How to not fail API client development ◦ Good

    architecture and best practice • Architecture and best practices in regular gem development ◦ Architecture techniques in API clients also help the other gem development 20 The Goal/Objective of this talk

21. • Why do I make API clients? • Responsibilities of

    API clients • My API clients and Tips • 7 Good Patterns of API clients 21 Agenda

22. 22 Topics covered today App Web APIs API client

23. • New technologies ◦ e.g. OpenAPI, microservices • API servers

    • non-text-based APIs ◦ APIs of which both requests and responses aren't in text format ◦ e.g. Protocol Buffers • non web APIs 23 Topics NOT covered today

24. • -> Why do I make API clients? • Responsibilities

    of API clients • My API clients and Tips • 7 Good Patterns of API clients 24 Agenda

25. • 4 cases 25 Why I make API clients Public

    APIs Private APIs Client developer == API developer 1 2 Client developer != API developer 3 4

26. • Pros: Convenient for API client users ◦ It’s the

    Official client ▪ Users don't have to worry which client to use ▪ Often kept secure. (since it's maintained officially) ▪ e.g. octokit(GitHub), newrelic-rpm(NewRelic), raven(Sentry.io) 26 1. Public APIs made by ourselves

27. • Cons: Tough for API client developers ◦ Multi-language support

    is a hard work 27 1. Public APIs made by ourselves

28. • Context ◦ Internal API ◦ All API users are

    internal (e.g. same company) 28 2. Private APIs made by ourselves

29. • If API creators make own API client gems, makes

    it easier to introduce services • API creator understands the specification most • Dog fooding 29 2. Private APIs made by ourselves

30. • There are mostly existing API clients gems for major

    services ◦ Search in https://rubygems.org/ • Recommended to use the official API client 30 3. Public APIs made by others

31. • Motivation ◦ Reinvention of wheel ◦ New services ◦

    Minor services 31 3. Public APIs made by others

32. • Context ◦ API for BtoB (Business to Business) service

    ◦ There aren't API clients in OSS, so we have to make it ourselves • BTW. In Japan, the most commonly used API documentation tool is Excel (xls, xlsx) ◦ Naturally there is no swagger 32 4. Private APIs made by others

33. • Case 1: in app repo ◦ e.g. app/, lib/

    ◦ I have actually seen this many times • Case 2: external gem ◦ e.g. in-house gem ◦ Even if for only 1 app, we should gemify 33 Where to place API client in our app?

34. • Tight coupling ◦ Implementation ◦ Release cycle 34 Cons

    of Case 1 (in app repo)

35. • Hard to CI ◦ Need to run all test

    suites ▪ Unit tests other than API client ◦ App testing tends to be time consuming ▪ 1 hour + (include E2E test) 35 Cons of Case 1 (in app repo)

36. • Loosely coupled with the app • CI finishes fast

    • Easy to maintain 36 Pros of Case 2 (external gem)

37. • Why do I make API clients? • -> Responsibilities

    of API clients • My API clients and Tips • 7 Good Patterns of API clients 37 Agenda

38. • tl;dr; ◦ Single Responsibility Principle (SRP) • API client

    responsibilities should be focused on making the target API (e.g Twitter, Facebook etc.) easy to use in the target language (e.g Ruby) • If extra functions are included, it is difficult to follow API specification changes 38 Responsibilities of API clients

39. • What API client should do • What API client

    should not do 39 Responsibilities of API clients

40. 1. Convert params from Ruby to HTTP 2. Wrap error

    code with Ruby class 3. Auto update access token 40 What API client should do

41. • In the Ruby world, we want to handle date

    with `Date`, and want to handle timestamp with `Time` • However, in the HTTP world it is necessary to convert it to `String` ◦ Format depends on API ◦ e.g. YYYY-MM-DD, YYYY/MM/DD • snake_case -> camelCase 41 1. Convert param from Ruby to HTTP

42. • Context ◦ Some APIs return error code in response

    body • Makes it easier for app to catch errors with rescue 42 2. Wrap error code with Ruby class

43. def create_message (message) with_error_handling do client.post( "/api/message" , message: message)

    end end def with_error_handling yield rescue Faraday::ClientError => error error_code = error.response.body[ "error_code"] error_class = ERROR_CODES[error_code] || BaseError raise error_class end 43 In API client gem code

44. begin api_client.create_message( "foo") rescue MyApi::InternalError # do something rescue MyApi::OtherError

    # do something rescue MyApi::BaseError # do something end 44 In app code

45. • c.f. Refactoring: Ruby Edition ◦ https://www.amazon.com/dp/0321984137 45 Extract Surrounding

    Method

46. • Hide the following in API client ◦ Access token

    expired error ◦ Update access token using refresh token ◦ Retry original API calling 46 3. Auto update OAuth2 access token

47. 47 3. Auto update access token class UserToken < AR::Base

    belongs_to :user def create_message with_retryable do api_client.create_message end end def with_retryable yield rescue AcessTokenExpiredError => error new_access_token, new_refresh_token = refresh_access_token user.update!( access_token: new_access_token, refresh_token: new_refresh_token, ) retry end end

48. 1. API Response caching 2. Request params validation 48 What

    API client should not do

49. • e.g. want to save API response in memcached for

    a fixed time • Requires dependency and config for memcached ◦ If we support cache backend other than memcached, it requires provider-style config • Requires complicated implementation for generalization ◦ Maintenance becomes difficult • This violates the SRP 49 1. API Response caching

50. • Only API know if request params is valid or

    not • Acceptable only when validating ◦ required params (use required keyword args) ◦ non-blank params ◦ using official schema 50 2. Request params validation

51. • Why do I make API clients? • Responsibilities of

    API clients • -> My API clients and Tips • 7 Good Patterns of API clients 51 Agenda

52. • OSS ◦ pixela ◦ chatwork-ruby • other in-house gems

    52 My API clients and Tips

53. 53 pixela

54. • https://github.com/sue445/pixela • pixela is client gem of Pixela 54

    pixela

55. • 55 Pixela (https://pixe.la/)

56. https://pixe.la/v1/users/sue445/graphs/tweets.html 56 e.g. My daily tweets

57. https://github.com/a-know/Pixela/releases/tag/v1.0.0 57 Pixela was launched at 2018/10/14

58. https://twitter.com/rubygems/status/1051823343517732865 58 client gem was released at 2018/10/15

59. 59 Tips. Use keyword args (even 1 or 2 args)

60. https://github.com/a-know/Pixela/releases/tag/v1.3.0 60 Tips. Use keyword args (even 1 or 2

    args)

61. 61 If I was NOT using keyword args... def graph_url(graph_id,

    date = nil) end def graph_url(graph_id, date = nil, mode = nil) end

62. https://github.com/sue445/pixela/pull/25/files 62 Since I was using keyword args... def graph_url(graph_id:,

    date: nil) end def graph_url(graph_id:, date: nil, mode: nil) end

63. 63 chatwork-ruby

64. • https://github.com/asonas/chatwork-ruby • API client for ChatWork (https://go.chatwork.com/) • I

    became a maintainer when I sent many PRs 64 chatwork-ruby

65. 65 Tips. Use official schema in test code

66. • Official schema (RAML) is provided at https://github.com/chatwork/api • Add

    RAML repo to gem repo as submodule 66 Tips. Use official schema in test code

67. https://github.com/asonas/chatwork-ruby/blob/v0.11.0/spec/lib/chatwork/message_spec.rb#L24-L36 67 Tips. Use official schema in test code describe

    ".create", type: :api do subject { ChatWork::Message.create(room_id: room_id, body: body, self_unread: self_unread, &block) } let(:room_id) { 123 } let(:body) { "Hello Chatwork!" } let(:self_unread ) { false } before do stub_chatwork_request( :post, "/rooms/#{room_id}/messages", "/rooms/{room_id}/messages" ) end it_behaves_like :a_chatwork_api , :post, "/rooms/{room_id}/messages" end

68. • API clients for internal service • API clients for

    external services used in business • About 10 gems 68 Other in-house gems

69. • Why do I make API clients? • Responsibilities of

    API clients • My API clients and Tips • -> 7 Good Patterns of API clients 69 Agenda

70. • What I think of when creating API clients 70

    7 Good Patterns of API clients

71. • Save labor of gem update • Use open-uri when

    only simple GET method 71 1. Keep dependency as minimal as possible require "open-uri" json = open("http://path/to/api" ).read res = JSON.parse(json)

72. • However, code could become redundant with net/http • Faraday

    can do anything ◦ https://github.com/lostisland/faraday • Suitable when supporting all CRUD requests • Faraday's request and response is pluggable: easy to handle special cases 72 2. Faraday is a silver bullet

73. 73 e.g. API that returns “true” and “false”

74. 74 e.g. API that returns “true” and “false” $ curl

    http://example.com/api/something true $ curl http://example.com/api/something false

75. 75 e.g. API that returns “true” and “false” connection =

    Faraday.new(url: "http://example.com" ) do |conn| conn.adapter Faraday.default_adapter end res = connection.get( "/api/something" ) res.body #=> "true" res.body.class #=> String

76. 76 I created https://github.com/sue445/faraday_boolean connection = Faraday.new(url: "http://example.com" ) do

    |conn| conn.response :boolean conn.adapter Faraday.default_adapter end res = connection.get( "/api/something" ) res.body #=> true res.body.class #=> TrueClass

77. 77 3. Make the subject stand out

78. 78 3. Make the subject stand out def create_message (consumer_key:,

    consumer_secret: , access_token:, access_token_secret: , message:) # Call API end

79. • Common variables used by all endpoints ◦ e.g. Auth

    • Variables used in specific endpoint ◦ Subject in endpoint 79 3. Make the subject stand out

80. 80 3. Make the subject stand out class Client def

    initialize(consumer_key:, consumer_secret:, access_token:, access_token_secret:) @consumer_key = consumer_key, @consumer_secret = consumer_secret @access_token = access_token @access_token_secret = access_token_secret end def create_message (message) # Call API end end

81. 81 4. Prefer keyword args to hash args

82. 82 4. Prefer keyword args to hash args # Ruby

    1.9 syntax def create_graph(args = {}) end # Ruby 2.1+ syntax def create_graph( graph_id:, name:, unit:, type:, color:, timezone: nil, self_sufficient: nil) end VS

83. • Required args and optional args are shown in code

    83 4. Prefer keyword args to hash args # Ruby 2.1+ syntax def create_graph( graph_id:, name:, unit:, type:, color:, timezone: nil, self_sufficient: nil) end

84. 84 5. Introduce parameter object

85. • It is difficult to use with 10+ args even

    if you use keyword args ◦ an Array of Hash is difficult to express in comment 85 5. Introduce parameter object # @param request [Array<Hash>] an Array of Hash # (key is name, message, content_type, ....) def create_content (request) # Send a request to API with XML end

86. 86 5. Introduce parameter object class CreateContentRequest # @!attribute name

    # @return [String] the name of the content attr_accessor :name # and many more args def initialize(name:, message: content_type: "article", ...) end def to_param { name: name, message: message, contentType: content_type, ... } end end

87. 87 5. Introduce parameter object # @param request [Array<CreateContentRequest>] def

    create_content (request) xml = request.map(&to_param).to_xml # send a request to API with XML end

88. • Pros ◦ Parameter object itself can have conversion method

    ◦ Easy to write and read comment • If it gets easier to write YARD comment, consider adopting parameter object ◦ https://github.com/lsegal/yard • c.f. Refactoring: Ruby Edition ◦ https://www.amazon.com/dp/0321984137 88 5. Introduce parameter object

89. 89 6. Method accessible response

90. • The right is Rubyish 90 6. Method accessible response

    contents = api_client.get_contents first_content_name = contents[0][“name”] names = contents.map do |content| content["name"] end contents = api_client.get_contents first_content_name = contents[0].name names = contents.map( &:name) VS

91. • Recommend to use mashify ◦ https://github.com/lostisland/faraday_middleware 91 6. Method

    accessible response connection = Faraday.new('http://example.com/api' ) do |conn| conn.response :mashify conn.adapter Faraday.default_adapter end

92. 92 7. curl is universal language

93. • When I create API client, I often ask questions

    about unclear things or bugs • Writing sample code in ruby is not appropriate ◦ Reason 1. API providers don't necessarily know Ruby ◦ Reason 2. This may be bugs or specification of Ruby. (instead of API) 93 7. curl is universal language

94. • curl isn’t dependent on a specific language • curl

    can express all contexts with oneliner 94 Why should we use curl ? $ curl -X GET “https://example.com/api/user” -H “X-ACCESS-TOKEN: $ACCESS_TOKEN” -H “X-ACCESS-SECRET: $ACCESS_SECRET”

95. • `curl 〜 | jq .` is good for reporting

    ◦ I always use this 95 Why should we use curl ? $ curl -X GET “https://example.com/api/user” -H “X-ACCESS-TOKEN: $ACCESS_TOKEN” -H “X-ACCESS-SECRET: $ACCESS_SECRET” | jq . { “name”: “sue445” }

96. • `curl 〜 | jq . | pbcopy` ◦ Copy

    response to clickboard (Mac only) 96 Why should we use curl ? $ curl -X GET “https://example.com/api/user” -H “X-ACCESS-TOKEN: $ACCESS_TOKEN” -H “X-ACCESS-SECRET: $ACCESS_SECRET” | jq . | pbcopy

97. • https://github.com/mauricio/faraday_curl ◦ This middleware logs your HTTP requests as

    CURL compatible commands so you can share the calls you're making with someone else or keep them for debugging purposes. 97 Auto debug logging in curl format

98. https://github.com/sue445/pixela/blob/v1.1.0/lib/pixela/client.rb#L55-L69 98 Example def connection(request_headers = user_token_headers) Faraday.new(url: API_ENDPOINT, headers:

    request_headers) do |conn| conn.request :json conn.response :mashify, mash_class: Pixela::Response conn.response :json conn.response :raise_error if Pixela.config.debug_logger conn.request :curl, Pixela.config.debug_logger, :debug conn.response :logger, Pixela.config.debug_logger end conn.adapter Faraday.default_adapter end end

99. 99 Example [1] pry(main)> @client.get_pixel(graph_id: "tweets", date: Date.new(2018, 9, 15))

    D, [2019-04-03T01:36:05.905606 #2167] DEBUG -- : curl -v -X GET -H 'X-USER-TOKEN: XXXXXXXXXXXX -H 'User-Agent: Pixela v1.1.0 (https://github.com/sue445/pixela)' -H 'Content-Type: application/json' "https://pixe.la/v1/users/sue445/graphs/tweets/20180915"

100. • There are many reasons to create an API client

     • Responsibilities of API clients are SRP • Tips in my API clients • API Client 7 Good Patterns • Read “Refactoring: Ruby Edition” • Happy coding 100 Conclusion