-
Notifications
You must be signed in to change notification settings - Fork 3
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
RESTful APIs + Clean URLs for cologne #117
Comments
These urls are of a style that I have seen with various Python web frameworks, such as Django and flask.
It may also be a feature of Ruby on Rails web framework, which may be what runs GitHub. It is probably an art to making such urls 'intuitive' to the user of a website. Essentially, the servers for these urls send the url to a routing function, which interprets the Another style of restful api is to use parameters:
This is the style that I know how to implement with php; and all the restful interfaces at Cologne sanskrit-lexicon site are of this form. It might be that using Apache rewrite rules (e.g. by an '.htaccess file reference) would be a way to turn the first style into the second style. Or maybe (probably) there is some way that php has to directly handle urls of the first type. The sending back of response in JSON is not particularly hard, whichever style of url is used. Since Still a third way of sending parameters is to send JSON to the server, e.g.
This is easy with JQuery .ajax If I'm not mistaken, this latter JSON way of sending from browser to server is the form @juhnowski Probaby the first thing that needs to be done is to have an inventory of all the restful (in style 2) interfaces that currently exist at Cologne; and a specification of the type of data returned. This would serve as a reference point for designing a better API, for whichever restful style we move towards. This will also give a basis for identifying what kinds of JSON objects (rather than just html string constants) the server should return in response to the restful inputs. |
From SEO - it's worst possible way. And for the user it's no good as well, right.
Do not think so. I usually do with mod rewrite. But I do not deal with APIs. |
Regarding implementation of point 1 .htaccess file
http://localhost/apitrial/suggest/PW/prefix/slp1/Dava/100
@funderburkjim |
So it seems easily doable to use more user friendly URLs with existing infrastructure (with very less modification too). |
Regarding implementation of API no. 2 - .htaccess file
http://localhost/apitrial/entries/PW/slp1/citra/deva/ignoreaccent gave following result चित्र
|
After experimenting a bit with Cologne server APIs, I feel that the work towards RESTful APIs + Clean URLs is just a bit of mod rewrite modules + some regex magic. Jim may like to list the current APIs (Long URL types). |
And it turns out to be damn easy. Server needs these two commands to enable mod rewrite
Then the following .htaccess file needs to be put in api folder in Cologne server.
|
I would go for http://www.sanskrit-lexicon.uni-koeln.de/MD/citra/SDI/
These service pages we will close for indexation. S for SLP1, D for devanagari, I for ignore accents. |
Doable, but seems non-intuitive. Currently making a list of existing APIs at Cologne. |
@drdhaval2785 Good research on htaccess. I tried one of your examples at Cologne as follows:
Usage example: This shows:
|
https://github.com/sanskrit-lexicon/Cologne/tree/master/api This houses various documentations I have started regarding Clean URL development. You can copy paste rewrite rules from there and see whether it rolls out well. |
Here is a way to get the whole url to be preprocessed by a php program --- .htaccess
####php program apitest/index.php
calling sequence
This index.php program could probably be quite elaborate. |
Address-bar problemOne thing that is undesireable in these approaches is that the browser address-bar gets changed to e.g., for the first example, the address bar changes to the rewritten form:
Is there some remedy for this? |
comment on the input parameters
|
At least it's short and SEO is kept in mind. Because
8 levels deep - we'll have indexation issues. I would want people to find not only the main page, but to find us googling for words as well.
Did not get the question? Get rid of |
Tried to do some research.
At the end of it all, .htaccess reads like this
|
This is a splendid project, gentlemen! @drdhaval2785 informed me about it on the https://groups.google.com/forum/#!topic/sanskrit-programmers/wdhMuXGpc1E thread, where I announced a similar API for all the dicts available with the stardict-sanskrit etc. projects. Some suggestions from my experience (see links in thread above) is that in terms of rapid development and maintainability (without sacrificing any of the frontend-backend separation):
That apart, some other feedback:
PS:
|
some starters may help. |
Not possible to have best of both worlds?
It is not yet configured to return JSON yet. I have currently piggybacked by rewrites on present Cologne scripts (which are made to return HTML). SO the documentation is ready. Rewrites are ready. Minor modifications on backend script or a version thereof is pending which returns JSON instead of HTML. That part is majorly Jim's lookout. |
@drdhaval2785 http://docs.couchdb.org/en/2.0.0/contents.html has a good intro. I found it quite simple to setup and use. (One another thing I like about couchdb is that you can replicate the db in couchbase-lite db files for offline use is mobiles etc..)
Certainly yes. Start with couchdb, write a very thin wrapper to translate the nice API you desire to the couchdb API while interacting with it. You might want to do it anyway to provide support for querying over ssl (ie https - couchdb2 is currently buggy there). |
2017-06-04 18:49 GMT+03:00 Vishvas Vasuki <notifications@github.com>:
some starters may help.
@drdhaval2785 <https://github.com/drdhaval2785>
http://docs.couchdb.org/en/2.0.0/contents.html has a good intro. I found
it quite simple to setup and use.
(One another thing I like about couchdb is that you can replicate the db
in couchbase-lite db files for offline use is mobiles etc..)
Not possible to have best of both worlds?
Certainly yes. Start with couchdb, write a very thin wrapper to translate
the nice API you desire to the couchdb API while interacting with it. You
might want to do it anyway to provide support for querying over ssl (ie
https - couchdb2 is currently buggy there).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#117 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC44z0WDOEAUa0QRswwgcRuDafthFQ4ks5sAtIWgaJpZM4M-OkH>
.
I have used CouchDB / PouchDB for years, its splendid
https://github.com/mbykov
…--
М.
http://diglossa.ru
xmpp://m.bykov@jabber.ru
|
Is it possible to add similar URL parsing to Also, we could then have an Apache rewrite rule to point from this type of URL
to this type
That is, we may not need that intermediary index.php URL-parser at all if I maybe missing something since I have not seen any code, but it seems to be a way to go about doing it. |
@funderburkjim and @drdhaval2785 let me introduce to you @artforlife Yakov, hope this time it's for real. He want's to see the frontend files (all of them) and I do not know how to help him with that. First of all |
See description of dictionary_init.sh. This indicates how to get local version. Such as integrated with local XAMPP server. Is this enough to get you started? |
Thanks a lot, again.
Hmm, no.
|
getword.phpIn the current setup, there is a 'getword.php' in two places:
Probably you want the apidev version. Here's how to get apidev.
Now you can access getword: Important Note: This display works for 'mw' because the web display for mw has also been installed: \c\xampp\htdocs\cologne\mw\web. If you don't have mw installed locally, you'll get a 'not found' message back from getword. Is this enough to get you started? I've lost track of what you are trying to accomplish here. |
Good Impression from first quick read of @artforlife 's notes . Will give it a try at Cologne when time permits. |
@funderburkjim Much appreciated. I shall try out your suggestions shortly and let you know how everything goes. |
@funderburkjim I was able to follow your directions; however, I cannot get the As you suggested, my directory structure looks like this:
If you have an idea of what I am missing, I'll be happy to hear it. Otherwise, I'll finish installing some tools and debug it tomorrow. |
Seems it will go this way. |
@artforlife ok, so you've got it running. Everything needed for the rewrite rule testing? |
We shall see. I'll play with that next. Do we know what the general steps for committing and testing are? |
I have a local version working. I was able to simplify it and perform the entire thing using only the rewrite rules. No additional Here is how it works. Inside the
As you can probably gather from the rewrite rule, our call to the API will need to look something like this: When executed in the browser, we get which is the same as the direct call There is a minor issue with styles not being applied, but I have not even cared to investigate. This is a POC (proof-of-concept) example rather than some polished, publishable snippet. Is this what we wanted to achieve? |
@artforlife thanks. Please see #117 (comment) for comparison - a bigger list of possible URLs. And need to know your opinion on #117 (comment) as well. The URL as you proposed is a possible solution. But there should be an alternative, twice shorter as described at #249 (comment) It's important. |
@funderburkjim, @gasyoun forwarded me your letter with "exercises." They seem straightforward. I have started on them, but need access to some repositories. Here is what I sent to @gasyoun regarding this:
Could you help us with this? Let me know if you have questions about anything. |
Are these URLs still current? Is this where we would like to go? Is it possible to get sample calls for each URL on this list? That is, I would like a call with real-life parameters for each end-point, so I can test it locally and then on the testing server. |
The URLs are still current. If you can shorten the left side of equations, better. Right side links mostly work. word = rAma These seem to be reasonable parameters |
I propose we do a two-stage roll-out. First, we implement URLs in their longer version. Once that is done, we can shorten them to the format you advocate. We should at least do this at the testing stage. This way it will be easier to control what we want and make changes. Once URL sequences are set, the shortening of words should be straightforward. The deployment to production can be done with the final version. |
Seems a good idea. Let us do it that ways.
|
@drdhaval2785 , @gasyoun , I am attaching the list of URLs as it appears to me after I parsed it and went over it. I would like you to double check it. I am particularly interested in knowing how you envision the calls to be made. Those are presented in the form of comments above each rewrite rule. Let us spec those out properly. Furthermore, the ones marked with a question mark deserve a closer look for one reason or another. If I am missing something or if there are inaccuracies, let us clarify them before I move on with further work.
|
And still has.
Sure
slp1 is good for several reasons and should be used by default in generating the URLs. What I say is:
Should be enough. Actually even MW can be used by default, in this case we can have only
without accent. |
What is Can you fill in the first call's parameters fully, as an example?
Also, on all of these we seem to be missing the dictionary parameter. Is that expected? The toy-example I made above used it: |
filter = output encoding for Sanskrit words
Yakov's string contains 5 elements, but So
would be
http://www.sanskrit-lexicon.uni-koeln.de/apitest/entries/PW/slp1/citra/deva/ignoreaccent redirects to (and is still a working example)
As per
We will have capital letters in URL anyway, because SLP1 is the way I propose we code the
@drdhaval2785 as stated bellow some thing can be taken for granted and should not be stated in all URLs. Instead of a long URL like the one quoted above I see: http://localhost/apitrial/entries/PW/slp1/citra/ Where SLP1 And so on. |
https://api.github.com/repos/drdhaval2785/siddhantakaumudi
Please look at the API structure of various links mentioned on this page. It is extremely intuitive.
Can we design similar APIs for cologne where the URL itself sends necessary information and we send back the response JSON?
UPDATE
https://github.com/sanskrit-lexicon/Cologne/blob/master/api/apidoc.md is the place where I will be tracking various existing Cologne APIs and their rewrite rules.
The text was updated successfully, but these errors were encountered: