-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added support for Dictionaries #10
base: master
Are you sure you want to change the base?
Conversation
Hello @Richard-Degenne, Nice to meet you! Thanks for submitting a PR. I will look through it in a couple of days. |
Hi @andhapp, I added support for another endpoint of the dictionary API. |
Any input on the current state of this PR? |
Sorry man! It's been failing on Travis. I will have a look at it tonight. It must be something in the setup. I have glanced through the PR and it seems okay. Will look through it again just to make sure. Thanks for your patience! |
Yes, the Travis error seems unrelated, but I can't say for sure.
No worries. :) |
README.md
Outdated
#### Adding entries to a dictionary | ||
|
||
``` | ||
entry = TextRazor::DictionaryEntry(id: 'my-entry', text: 'Text to be matched') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DictionaryEntry
and Dictionary
should be internal classes, IMHO. The API interface should be something like this:
client = TextRazor::Client.new('api_key')
client.create_dictionary('my-dictionary')
# This can have keyword arguments but I'd not do it if it's not anywhere else in the library, makes it inconsistent
client.create_dictionary_entries('my-dictionary', {id: 'my-entry', text: 'Text to be matched'})
These method calls create_dictionary
and create_dictionary_entries
should return the actual instances of Dictionary
and DictionaryEntry
but there is no need for the consumer to know how to create these instances. client
hides that behind a facade and for a good reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I'll rework these parts.
lib/textrazor/api_client.rb
Outdated
@@ -0,0 +1,36 @@ | |||
require 'rest_client' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the main reason to separate this out into an api_client
class? `
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I'll rework this part.
lib/textrazor/request.rb
Outdated
end | ||
|
||
private | ||
|
||
def self.build_query(text, options) | ||
query = {"text" => text, "apiKey" => options.delete(:api_key)} | ||
query = {"text" => text} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing it from here means this is not duplicated across 4 or 5 different methods. Any particular reason to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API key must be passed as a x-textrazor-key
header.
As of today, this is not an issue because the only endpoint supported by the gem is a POST
request, but adding support for dictionaries means supporting GET
, PUT
and DELETE
requests.
|
||
module TextRazor | ||
|
||
class ApiResponse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to ApiRequest
, Response
class was meant to take care of this responsibility. Any particular reason to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Response
class is heavily oriented towards parsing responses to analysis requests.
The more general ApiResponse
can handle any kind of response from TextRazor. (Side note: Response
inherits from ApiResponse
)
Hey @Richard-Degenne, I had a look at the PR and left some comments on it. |
Thanks for the review! I'm a bit snowed under at the moment, but I'll look into your remarks as soon as I have a moment. |
Hi @andhapp, It's been a while, but I intend to work on this PR in the coming days. I'll answer your reviews and rework some things here and there. |
c818ca2
to
9f11997
Compare
Hi @andhapp, I rebased the branch onto |
Thanks. I've reviewed your other PR. Will look at this one next. |
9f11997
to
07dcd06
Compare
Hi @andhapp, Since the other PR got merged (thanks for that, btw), I rebased this one onto |
Hi @andhapp, Any input on the current state of this PR? :) |
Hi @andhapp, Allow to bump. I understand you have some problems with GitHub notifications, so maybe this one will get through. 😛 |
This PR adds basic support for TextRazor's dictionary features.
It adds 4 new endpoints to the API :
The PR also revamps the way requests are handled, since until now, only the analysis API was considered.