How to make spree, rails and liqpay to work together? - ruby-on-rails-4

I have a Rails application with Spree. I need to use Liqpay for payment and i have some troubles with it's API. I have inserted Liqpay button it is looks like
<a href="https://www.liqpay.com/api/pay?public_key=<public_key>&private_key=<private_key>&signature=<%=#sign%>&amount=<%=#order.total%>&order_id=<%= #order.id%>currency=RUB&description=Desc&type=buy&sandbox=1&pay_way=card,delayed&server_url=<my_site_api_url>&language=ru&return_url=<return_url>">
signature #sign is calculated using gem Lickpay https://github.com/leonid-shevtsov/liqpay
request = Liqpay::Request.new (<some_params>)
#sign = request.signature
this is not exectly the way, described in Liqpay docs, but that does not work too((
There is a way to make requsts to Spree without signature, but a can't cend order_id in this case, but I need it. Is there a way to calculate it correctly, or to deal without it? How I will get to know order_id in this case? Thank you!

Fiinally, made it. It is pretty easy and clear, what I had to is read documentation on Liqpay carefully. So, the first is on need to install this lib - https://github.com/liqpay/sdk-ruby
and then follow liqpay guides! One thing one need to note - is that signature should be calculated with exactly the same params, request to Liqpay Api is made.

Related

CookieAuthenticator restlet

I have built some RESTful api's with REstlet 2.3.4. I've been using HTTP_BASIC which let the browser prompt for credentials but it's time for a proper login form. I figure the easiest way to implement this is CookieAuthenticator. I can't find full working examples on github/google. I am sure i'm over looking them can someone provide a working example implementing CookieAuthenticator in Restlet?
I did get this to work after all. I have a longer answer here with some code examples. First, i was missing the fact that CookieAuthenticator is a filter and HAS the logic to handle login and logout. You need to create EMPTY ServerResources with a method annotated with #Post that has nothing in the body. Second, extend CookieAuthenticator and overwrite isLoggingIn(..) and isLoggingOut(..) with the code found in the link.
Cheers,
-ray

Correct yummly API call for a recipe

I'm trying to use the Yummly API. I've noticed that some of their developers have answered other questions here, so I'm hoping to catch their eye. I used the documentation at the yummly developer site https://developer.yummly.com/documentation#IDs.
Specifically here is my get request:
<http://api.yummly.com/v1/api/recipe/Avocado-cream-pasta-sauce-recipe-306039>
Which returns this:
Please include X-Yummly-App-ID and X-Yummly-App-Key
Seems like this is a sensible thing, except that I don't see anywhere in the documentation for the single recipe call where I'm supposed to insert that info. Any one out there know how to properly format this?
or include them as URL parameters:
_app_id=app-id&_app_key=app-key
https://developer.yummly.com/documentation#IDs
Try this:
http://api.yummly.com/v1/api/recipe/Avocado-cream-pasta-sauce-recipe-306039?_app_id=ID&_app_key=KEY
You need to take the URL you mentioned in the question and add your authentication parameters to it. So it becomes:
http://api.yummly.com/v1/api/recipe/Avocado-cream-pasta-sauce-recipe-306039?_app_id=ID&_app_key=KEY
Instead of ID and KEY insert the application id and key from your account on developer.yummly.com

RESTful API and Foreign key handling for POSTs and PUTs

I'm helping develop a new API for an existing database.
I'm using Python 2.7.3, Django 1.5 and the django-rest-framework 2.2.4 with PostgreSQL 9.1
I need/want good documentation for the API, but I'm shorthanded and I hate writing/maintaining documentation (one of my many flaws).
I need to allow consumers of the API to add new "POS" (points of sale) locations. In the Postgres database, there is a foreign key from pos to pos_location_type. So, here is a simplified table structure.
pos_location_type(
id serial,
description text not null
);
pos(
id serial,
pos_name text not null,
pos_location_type_id int not null references pos_location_type(id)
);
So, to allow them to POST a new pos, they will need to give me a "pos_name" an a valid pos_location_type. So, I've been reading about this stuff all weekend. Lots of debates out there.
How is my API consumers going to know what a pos_location_type is? Or what value to pass here?
It seems like I need to tell them where to get a valid list of pos_locations. Something like:
GET /pos_location/
As a quick note, examples of pos_location_type descriptions might be: ('school', 'park', 'office').
I really like the "Browseability" of of the Django REST Framework, but, it doesn't seem to address this type of thing, and I actually had a very nice chat on IRC with Tom Christie earlier today, and he didn't really have an answer on what to do here (or maybe I never made my question clear).
I've looked at Swagger, and that's a very cool/interesting project, but take a look at their "pet" resource on their demo here. Notice it is pretty similar to what I need to do. To add a new pet, you need to pass a category, which they define as class Category(id: long, name: string). How is the consumer suppose to know what to pass here? What's a valid id? or name?
In Django rest framework, I can define/override what is returned in the OPTION call. I guess I could come up with my own little "system" here and return some information like:
pos-location-url: '/pos_location/'
in the generic form, it would be: {resource}-url: '/path/to/resource_list'
and that would sort of work for the documentation side, but I'm not sure if that's really a nice solution programmatically. What if I change the resources location. That would mean that my consumers would need to programmatically make and OPTIONS call for the resource to figure out all of the relations. Maybe not a bad thing, but feels like a little weird.
So, how do people handle this kind of thing?
Final notes: I get the fact that I don't really want a "leaking" abstaction here and have my database peaking thru the API layer, but the fact remains that there is a foreign_key constraint on this existing database and any insert that doesn't have a valid pos_location_type_id is raising an error.
Also, I'm not trying to open up the URI vs. ID debate. Whether the user has to use the pos_location_type_id int value or a URI doesn't matter for this discussion. In either case, they have no idea what to send me.
I've worked with this kind of stuff in the past. I think there is two ways of approaching this problem, the first you already said it, allow an endpoint for users of the API to know what is the id-like value of the pos_location_type. Many API's do this because a person developing from your API is gonna have to read your documentation and will know where to get the pos_location_type values from. End-users should not worry about this, because they will have an interface showing probably a dropdown list of text values.
On the other hand, the way I've also worked this, not very RESTful-like. Let's suppose you have a location in New York, and the POST could be something like:
POST /pos/new_york/
You can handle /pos/(location_name)/ by normalizing the text, then just search on the database for the value or some similarity, if place does not exist then you just create a new one. That in case users can add new places, if not, then the user would have to know what fixed places exist, which again is the first situation we are in.
that way you can avoid pos_location_type in the request data, you could programatically map it to a valid ID.

Django URL Aliases

I'm new to Django and I have a BIG problem. I don't like the "url pattern" philosophy of Django.
I don't want my pages to look like
http://domain.com/object/title-of-object
I want
http://domain.com/title-of-object
and of course I will have more than one type of object.
Is there an elegant way to achieve this with Django (not using hard-coded urls)?
Thanks!
Ever wondered that, if what you want to do seems so hard to acheive, you're doing it wrong? What is so wrong with /foo/name-of-foo/ ?
I'm trying to imagine your use-case and wondering if you need 'human' URLs for only a handful of pages. If so, it would work to go with the /foo/slug-for-foo/ approach but then use the django.contrib.redirects app to support hand-written URLs that redirect to the saner, more RESTful ones?
It is possible. You'll have to create one catch-all URL pattern, for which you'll create a view that will search all possible object types, find the matching one, and process and return that. Usually, this is a bad idea.

Ember.js routing with parameters

I just played with ember routing example. It looks quite interesting. Especially if you are going to build all your application on Ember framework.
But parameters in url follows after '#'. That means you can't copy and send a link to someone if client has to login with postback (if only to set a cookie with login parameters). Is there a better option - maybe use '?' instead of '#'?
You may also have a look at Ember.Router.
There are two good start points # https://gist.github.com/2679013 and https://gist.github.com/2728699
A lot of fixes have been made the last couple of days.
EDIT
A brand new guide is now available # https://emberjs-staging-new.herokuapp.com/guides/outlets#toc_the-router
Here is a full example courtesy of https://github.com/jbrown
http://jsfiddle.net/justinbrown/C7LrM/10/