tomas-stefano/jeckle

Create client APIs with easiness and flexibility.

jeckle's Issues

Add Restful actions

class MyApiResource
  include Jeckle::Resource
  api :some_api
  rest_actions except: [:delete]
end

TO DO

• Create rest_actions into module HTTP
• Add options only and except
• .find => GET /posts/:id
• .create => POST /posts
• #save => POST /posts
• #update => PATCH /posts
• #destroy => DELETE /posts/:id

See the latest version and improve the Readme

The latest version is not in the Readme documentation, so we need to update the Readme.

Rename `search` to `fetch` on Jeckle::Resource

Hey, what do you guys think about calling the method that gets all resources fetch? I think it makes more sense.

I also thought that it doesn't imply in passing in a hash of options, so we could have another method, or an alias, called where, like so:

# gets only Java projects
$ Project.where(language: 'Java')

# gets all projects
$ Project.fetch

Fix Coverage bug

After move out fixtures our test coverage decreased because SimpleCov isn't considering the fixtures method calls:

Weird bug :-P

Allow action to determine a serializer for submiting data

Define an option serializer, which will be used to build the request body when performing a POST/PUT/PATCH action.

class Product
  include Jeckle::Resource
  api :mercado_libre

  action :checkout, method: :post, serializer: ProductCheckoutSerializer
end

The serializer must respond to to_json. http://github.com/mateusg/jbuilder_serializer may be useful.

Provide serializer option for when submiting data

Irregular APIs have weird actions that require unimaginable bodies, would be awesome if we got able to specify a per action serializer.

Make All Core API Options Registerable

• headers
• base_uri
• namespaces
• basic_auth
• logger

Jeckle::API intermittent spec on jruby, rbx and ruby-2.0.0 build

When running the examples on jruby or rbx, sometimes I get an error on Jeckle::API#connection spec:

Failures:

  1) Jeckle::API#connection assigns timeout options
     Failure/Error: expect(jeckle_api.connection.options.open_timeout).to eq 2

       expected: 2
            got: nil

       (compared using ==)
     # ./spec/lib/jeckle/api_spec.rb:37:in `__script__'
     # kernel/common/eval.rb:101:in `instance_exec'
     # kernel/bootstrap/array.rb:97:in `map'
     # kernel/bootstrap/array.rb:97:in `map'
     # kernel/bootstrap/array.rb:97:in `map'
     # kernel/common/kernel.rb:498:in `load'
     # kernel/delta/code_loader.rb:66:in `load_script'
     # kernel/delta/code_loader.rb:152:in `load_script'
     # kernel/loader.rb:656:in `script'
     # kernel/loader.rb:810:in `main'

Finished in 0.7139 seconds (files took 2.07 seconds to load)
83 examples, 1 failure

Failed examples:

rspec ./spec/lib/jeckle/api_spec.rb:36 # Jeckle::API#connection assigns timeout options

Randomized with seed 40473

It also happens with seed 26503. I think it has something to do with Faraday.

Configurable Faraday Middlewares through API definition

ad34d3c#diff-16a46cac5fa22f9193a0ee16bcc8b7f5R15

Document code with YARD

http://www.rubydoc.info/gems/yard/file/docs/GettingStarted.md

❤️

Error Handling on non successful responses

• @mateusg

  Perhaps it's time to have something like Jeckle::RequestError with status, message and other information provided by Faraday's response. Or even create a class to encapsulate Faraday's response.

• @brennovich

  Not sure if we should break user's application when getting a 404. I see users doing this all the time while using Jeckle (override #search method and caring about successful responses only), I know isn't the better way but we already log requests and responses.

• @mateusg

  Maybe this behaviour should be configuration oriented.

config.raise_on_request_errors!

Shell command to list APIs, resources and actions

The context:

Imagine that you need to handle many resources with complex actions or many nested resources in your client API. Example: a store that needs to handle payments, orders, products, comments about the products and so on.

Compare with the other side of the game. We have rake routes for Rails applications. Why not have the other way around?

This is a feature, just to you all have in mind ... that has a main objective: to be more user-friendly or the user best-friend (Hey, Old chap!).

We can discuss more of this, but here there are some ideas:

  $ jeckle resources

SomeService:  http://api.some-service.com/

  - SomeService::Book
      Method    URI
      .fetch    /v1/books
      .find     /v1/books/:id
      #save     /v1/books
      #update   /v1/books/:id
      #destroy  /v1/books/:id

  - SomeService::Comment
      Method    URI
      #save     /v1/books/:book_id/comments
      #update   /v1/books/:book_id/comments/:id
      #destroy  /v1/books/:book_id/comments/:id

  - SomeService::Payment
      Method    URI
      .find     /v1/payments/:id
      #save     /v1/payments

Other API

  - OtherAPI::Product
      Method    URI
      .fetch    /v1/products
      .find     /v1/products/:id
      #save     /v1/products
      #update   /v1/products/:id
      #destroy  /v1/products/:id

  - OtherAPI::Payment
      Method    URI
      #save     /v1/payments/
      #cancel  http://cancel-app.com/api/v1/payments/:id/cancel # This is where the complexity begins

This is not priority, is just a epiphany that I had right now when begin to play with the jeckle to handle two APIs here.

Can't create a base class for my API model

If I want to have common code for my API models into a base class, like so:

module MyAPI
  class Base
    include Jeckle::Resource
    default_api :food

    def some_helper
      1 + 1
    end
  end
end

module MyAPI
  class Cocada < Base
  end
end

I get this error:

NoMethodError: undefined method `connection' for nil:NilClass
 from /Users/mgomes5/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/bundler/gems/jeckle-4aae9801d3ac/lib/jeckle/request.rb:24:in `perform_api_request'

I think we can think of some way to store class variable without having this problem. Will try to help with this soon.

Friendly Error Messages

NoSuchAPIError:

Oh Mr. Jeckle, what we can do now?
Heckle, you're stupid, you need to put the right name for apis!
Tell me the APIs then, you moron!
Dribble, Twitter!

Conflict of params and options on new Jeckle Request

Jeckle::Request currently receives options and params mixed in a single parameter options. It extracts the values considered as request options (method, body and headers), then assigns the remaining values to the params hash.

def initialize(api, endpoint, options = {})
  # ...
  @method  = options.delete(:method) || :get
  @body    = options.delete(:body) if %w(post put).include?(method.to_s)
  @headers = options.delete(:headers)
  # ...
  @params = options
end

If for some reason our request needs to send a query parameter named method, body or headers, it won't work, they will simply be removed from the params hash.

I suggest we separate options from the params hash. Tell me what you guys think.

Add Rubocop

Replace Faraday with Hurley

More details: lostisland/faraday#454

Jeckle::Request

A component that handles the API connection based on a registered API configuration.

• Setup a Jeckle::Request based on a registered API
• Initializes when invoked in a Jeckle::Resource.default_api https://github.com/tomas-stefano/jeckle/wiki/DSL-Definition#resource-definition-and-usage
• Cache Jeckle::Request instance, if more than one Jeckle::Resource uses a registered API we shouldn't have to initialize it more than once

See examples directory and add the examples link to the Readme.

We need to see if the examples directory is working with the master version and add a link to the Readme.

Typo

Friends, "easyness" is wrong. The correct would be "easiness" (project README and GitHub description). 👍

Use Faraday instead HTTParty

Custom Parser Support

• Add parse options when reading APIs

To discuss: Act directly on FaradayMiddlewares

Define Jeckle::Resource API and DSL

Draft:

module MyApi
  class Product 
     include Jeckle::Resource

     base_uri 'myapi.com'
     logger Rails.logger # or any other logger
     filter :password, :sensitive_data # show [FILTERED] in the logger.
     options version: 'v2'
     headers 'Content-Type' => 'application/whatever.complex.header.v2+json;charset=UTF-8'
     basic_auth username: 'chucknorris', password: 'nowThatYouKnowYouMustDie'
  end
end

Product.all        # => /products
# => Logger: "GET my_api.com/products \n Headers: {}"
Product.find(1) # => /products/1
# => Logger: "GET my_api.com/products/1 \n Headers: {}"

Product.new(attributes).save
# => Logger: "POST my_api.com/products \n Params: {...}, Headers: {}"

Destroy/Put/Patch as the same.