My company is reworking its API and wants to make everything RIGHT for this time ;) Thats the setup...
We are delivering data to clients over the internet.
Clients are mobile handsets like iPhone, Androids, J2ME, Blackberry...
The server is coded in Ruby on Rails
We want to achieve through a framework...
Take use of ActiveResource on the clients.
The framework should do the connection (REST), parsing and (dynamically) providing of models
Licence must be open source.
Authorization shall be included. We use OAuth and need to deliver the Access Token on any request. Maybe as parameter or in the HTTP-Header?
HTTPS/SSL support
Pagination and Relationships (with lazy loading) support would be great! Otherwize the framework must be able to be adjusted for these things.
We already have found following frameworks and kindly ask you guys to evaluate them. Maybe one of you used some of them or something different...
Android: RESTProvider from Novoda / Carl-Gustaf Harroch
Providers offer an abstraction from data sources on Android and the RESTProvider Automatically parses RESTful API responses into a Provider. RESTProvider is an implementation of all commonly re-implemented functionality when dealing with web services in Android. Users can seamlessly interface with any Web Service API which provides JSON or XML as a response. To query a RESTProvider in an activity a user need only specify an endpoint and then query an APIs RESTful functions. RESTProvider also handles all HTTP querying & caching.
Haven't found much documentation other than that
Provides caching as well
Release + Documentation is planned for early 2011
iOS: http://iphoneonrails.com/
Lib for communication between iOS and Rails
RESTful and "ActiveResource"-based
includes XML/JSON Parser
free licence
pagination?, android?, lazy loading?
Android: Hand made approach with the use of cursors backed by a SQLLite DB
intended to be very performant and best practice of Android
uses cursors
Android: Spring Android Rest Template Module
Spring's RestTemplate is a robust, popular Java-based REST client. The Spring Android Rest Template Module provides a version of RestTemplate that works in an Android environment.
Android: You always should take a look at this video of Google IO 2010 when thinking serious about REST
Android: Feed Framework
com.google.android.feeds
A collection of classes to help you build content providers. The framework is specially designed to help connect your application to Web APIs.
I am the author of the RESTProvider. Still very early stage so I would not recommend to use it in production. I have been using it on several projects which are in production but I adapted most the code to specific needs. I will try to get a public stable API by the end of the year.
In regards to reworking the API, I would suggest the following:
Use GZip compression
Use ETags for caching
Use standards with no modification (I saw cases where the naming changed from oauth_token to my_token which makes most library useless without modification) - OAuth/REST
Use creation/modified timestamp and remote ids for all objects in order to enable caching client side (SQLite conflict clauses):
{"myobject": {"createdAt": xxxx, "rid": "hashvalue"}}
4a. Use a good way to identify the object returned for user/activity/application: opensocial uses "application id" + "user id" + "activity id"
Prefer JSON over XML
Prefer simplicity (lowest depth possible)
Return the full object with the one to many relationship within that object:
{"parent":....
"has": {"full object not just the ID"}
}
Don't return IDs only ( "category": [ 2,3,4] should be "category": [{"name": "testing", "id": 2},{"name": "production", "id": 3 }} )
Consider each call to be independent of each other (i.e. I should have enough information for call http://test.com/object.json to populate my views)
For documentation:
1. provide test servers
2. provide cUrl for testing
3. provide sample scripts in java/php/ruby etc...
That s all I can think for now. I might add ontop of this as I come with more suggestion.
I'd recommend taking a look at RestKit for iOS
High performance, threaded network layer with a simple API for request/responses
Object mapping system for mapping remote payloads into local objects declaratively (including relationships)
Integration with Core Data for providing a fast local cache of remote data with synchronization capabilities
Support for generating a seed database from a series of JSON payloads
Specific support for integrating with Ruby on Rails backends (RKRailsRouter)
Apache licensed
Used in production in a number of excellent apps (i.e. Gate Guru)
Just to add to Spring RestTemplate choice. Here is link for SSL https calls. Hope this helps others. Was looking for this solution a long time.
http://www.makeurownrules.com/secure-rest-web-service-mobile-application-android.html
Related
We are in the process of designing a front-end application with Angular which will call a jBASE server through RESTful APIs. APIs are created from jBASE component called jAgent.
Does jAgent support creating and verifying JWTs?
If not, what is the best way to handle authentication/authorization for the Angular application?
If we need to use JWTs, do we have to use a authentication middleware application (.NET Core or node.js) for that?
Great question! At the moment there is no handler within jAgent and our recommendation is to implement this, and advanced web server/API gateway technology by way of other applications like HAproxy or Kong.
An expansion of jAgent functionality to include things like this is something we're still considering but keep in mind, the power of jBASE lies in its native interactions with the host OS. Since there is no virtual OS layer it can be easier to plug and play off the shelf things to fill in for additional functionality, which gives you the flexibility to bring your own tooling.
In summary:
Not at the moment
Using an off the shelf package to act as your API gateway
Subject to the package you choose
That relegates jAgent to management of the API layer as it exists on the PICK/jBASE side while the off the shelf package manages your API security layer.
One other note for you--I noticed that you included a link to the old jBASE docs hosted on HelpJuice. It's worth mentioning that we've migrated those docs to docs.zumasys.com. You'll find the docs there to be more up to date, and also completely open sourced--part of the migration included their move to a GitHub repo, where we're happy to take community contributions.
For reference, the article you mentioned is available at https://docs.zumasys.com/jbase/connectivity/jagent/introduction-to-jagent-rest-services/.
Update:
One of our engineers has a program that will use openssl to generate the tokens for you, which you can find at https://github.com/patrickp/wjwt.
You will need openssl installed on the machine and in the path.
The WJWT.TEST program shows the usage. The important piece is the SECRET.KEY which is your internal KEY you use to sign the payloads.
When a user first authenticates you create the token with SIGN. Claims are any items/fields you wish to save/store. Do NOT put sensitive data in here as it is viewable by anybody. The concept is we sign this with our key, give it back to the client. On future calls the client sends the token and we pull it and call the VERIFY function which basically re-signs the payload and validates the signatures match. This validates the payload was not manipulated.
Activities such as expiration you would build into your code.
Long term we plan to take this library and refactor the code into our MVDB Toolkit library with more functionality. That library is something we provide to jBASE customers at no additional charge.
Let's suppose I was going to design a platform like Airbnb. They have a website as well as native apps on various mobile platforms.
I've been researching app design, and from what I've gathered, the most effective way to do this is to build an API for the back-end, like a REST API using something like node.js, and SQL or mongoDB. The font-end would then be developed natively on each platform which makes calls to the API endpoints to display and update data. This design sounds like it works great for mobile development, but what would be the best way to construct a website that uses the same API?
There are three approaches I can think of:
Use something completely client-side like AangularJS to create a single-page application front end which ties directly into the REST API back-end. This seems OK, but I don't really like the idea of a single-page application and would prefer a more traditional approach
Create a normal web application (in PHP, python, node.js, etc), but rather than tying the data to a typical back end like mySQL, it would basically act as an interface to the REST API. For example when you visit www.example.com/video/3 the server would then call the corresponding REST endpoint (ie api.example.com/video/3/show) and render the HTML for the user. This seems like kind of a messy approach, especially since most web frameworks are designed to work with a SQL backend.
Tie the web interface in directly in with the REST api. For example, The endpoint example.com/video/3/show can return both html or json depending on the HTTP headers. The advantage is that you can share most of your code, however the code would become more complex and you can't decouple your web interface from the API.
What is the best approach for this situation? Do you choose to completely decouple the web application from the REST API? If so, how do you elegantly interface between the two? Or do you choose to merge the REST API and web interface into one code base?
It's a usually a prefered way but one should have a good command of SPA.
Adds a redundant layer from performance perspective. You will basically make twice more requests all the time.
This might work with super simple UI, when it's just a matter of serializing your REST API result into different formats but I believe you want rich UI and going this way will be a nightmare from both implementation and maintainance perspective.
SUGGESTED SOLUTION:
Extract your core logic. Put it into a separate project/assembly and reuse it both in your REST API and UI. This way you will be able to reuse the business logic which is the same both for UI and REST API and keep the representation stuff separately which is different for UI and REST API.
Hope it helps!
Both the first and the second option seem reasonable to me, in the sense that there are certain advantages in decoupling the backend API from the clients (including your web site). For example, you could have dedicated teams per each project, if there's a bug on the web/api you'd only have to release that project, and not both.
Say you're going public with your API. If you're releasing a version that breaks backwards compatibility, with a decoupled web app you'd be able to detect that earlier (say staging environment, given you're developing both in-house). However, if they were tightly coupled they'd probably work just fine, and you'll find out you've broken the other clients only once you release in production.
I would say the first option is preferable one as a generic approach. SPA first load delay problem can be resolved with server side rendering technique.
For second option you will have to face scalability, cpu performance, user session(not on rest api of course because should be stateless), caching issues both on your rest api services and normal website node instances (maybe caching not in all the cases). In most of the cases this intermediate backend layer is just unnecessary, there is not any technical limitation for doing all the stuff in the recent versions of browsers.
The third option violates the separation of concerns, in your case presentational from data models/bussines logic.
this is a general 'what technologies are available' question.
My company provides a web application with a RESTful API. However, it is too slow for my needs and some of the results are in an awkward format.
I want to wrap their restful server with a proxy/adapter server, so when you connect to the proxy you get the RESTful API I wish the real one provides.
So it needs to do a few things:
passthrough most requests
cache some requests
do some extra requests on the original server to detect if a request is cacheable
for instance: there is a request for a field in a record: GET /records/id/field which might be slow, but there is a fingerprint request GET /records/id/fingerprint which is always fast. If there exists a cache of GET /records/1/field2 for the fingerprint feedbeef, then I need to check the original server still has the fingerprint feed beef before serving the cached version.
fix headers for some responses - e.g. content-type, based upon the path
do stream processing on some large content, for instance
GET /records/id/attachments/1234
returns a 100Mb log file in text format
remove null characters from files
optionally recode the log to filter out irrelevant lines, reducing the load on the client
cache the filtered version for later requests.
While I could modify the client to achieve this functionality, such code would not be re-usable for other clients (different languages), and complicates the client logic.
I had a look at whether clojure/ring could do it, and while there is a nice little proxy middleware for it, it doesn't handle streaming content as far as I can tell - the whole 100Mb would have to be downloaded. Also it doesn't include any cache logic yet.
I took a look at whether squid could do it, but I'm not familiar with the technology, and it seems mostly concerned with passing through requests rather than modifying them on the fly.
I'm looking for hints where I might find the correct technology to implement this. I'm mostly language agnostic if learning a new language gets me access to a really simple way to do it.
I believe you should choose a platform that is easier for you to implement your custom business logic on. The following web application frameworks provide easy connectivity with REST APIs, and allow you to create a web application that could work as a REST proxy:
Play framework (Java + Scala)
express + Node.js (Javascript)
Sinatra (Ruby)
I'm more familiar with Play, of which I know it provides utilities for caching you could find useful, and is also extendable by a number of plugins.
If you are familiar with Scala, you could have a also have a look at Finagle. It is a framework build be Twitter's infrastructure team to provide protocol-agnostic connectivity. It might be an overkill for REST to REST proxy, but it provides abstractions you might find useful.
You could also look at some 3rd party services like Apitools, which allows to create a proxy programmatically (in lua). Apirise is a similar service (of which I'm a co-founder) that intends to do provide similar functionalities with a user-friendly UI.
Beeceptor does exactly what you want. It plugs in-between your web-app and original API to route requests.
For your use-case of caching a few responses, you can create a rule. That way it shall not hit the original endpoint.
The requests to original APIs can be mocked, and you can inspect response
You can simulate delays.
(Note: it is a shameless plug, I am the author of Beeceptor and thought it should help you and other developers.)
https://github.com/nodejitsu/node-http-proxy is looking useful - although I don't yet know if it can stream process for transcoding.
I'm, going to write a web app, which should be CRUD accessible from both, the web and native mobile device apps. For the latter i'm definitely committed to a REST API. Is it possible to realize that with Meteor.com ? Would it be an option to use Meteor for just the web and a second REST interface to directly talk to the mongo? Since the meteor client listens for changes in the mongodb this should not cause conflicts, does it?
As of 2015, look at Gadi's answer for the Meteorpedia entry on REST APIs, and at krose's answer comparing REST API packages. Discussion for folding REST APIs into core is on Hackpad. This question is a duplicate of How to expose a RESTful service with Meteor, which has much better answers. -- Dan Dascalescu
Old answer (2012) below.
For adding RESTful methods on top of your data, look into the Collection API written for Meteor:
https://github.com/crazytoad/meteor-collectionapi
As for authentication for accessing the database, take a look at this project:
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth
Both are definitely infantile in development, but you can create a RESTful API and integrate it with a mobile native client pretty easily.
There are a lot of duplicates of this question. I did a full write-on on this in Meteorpedia which I believe covers all issues:
http://www.meteorpedia.com/read/REST_API
The post reviews all 6 options for creating REST interfaces, from highest level (e.g. smart packages that handle everything for you) to lowest level (e.g. writing your own connectHandler).
Additionally the post covers when using a REST interface is the right or wrong thing to do in Meteor, references Meteor REST testing tools, and explains common pitfalls like CORS security issues.
If you are planning to develop a production application, then Meteor is not an option right now. Its under constant change, and there are still many common features it has to support before its ready to use, which will be quite some time.
For your Question, Somebody has already asked and answered the question about support for file uploading in meteor(also contains HTTP handing related information).
How would one handle a file upload with Meteor?
I'm thinking about creating an application for the iPhone and Android that will need to access a common backend to retrieve account information. Can both access a web service over https? What other way would allow me to have one interface to the backend that is accessible by both?
They both work over http and https which is a common enough protocol. I would suggest you go with a RESTful web service so you expose your service via URI's like http://www.myservice.com/weather/zip/98007 which would return an XML blob that can be parsed by the client.
if you are starting from nothing, i'd definitely go with RESTful service that returns/accepts JSON... there are plenty of libraries for both platforms that will accept JSON and turn it into arrays and dictionaries.
I'd recommend using a RESTful web service backend, which is all standard HTTP and/or HTTPS. If you can use Ruby on Rails, its default scaffolding will get you about 99% of the way there and for the iPhone there is an open source project called ObjectiveResource that will automate your communication with this Rails backend. I haven't investigated yet what options are available on Android but since it is all simple HTTP it should be straightforward. I am not the maintainer of ObjectiveResource but I have contributed some code. You can check it out here:
http://iphoneonrails.com
One good approach I have seen used with other services is to write the backend in such a way that it can feed data back in different types - for Android an XML response is best, but for the iPhone sending back plist data is preferred (though it can also work with XML if required). In both cases it's easier to simply POST updates back to the server than to wrap an update in XML.
Both platforms should be able to use whatever form of authentication you wish to use, the iPhone I know supports all methods of HTTP authentication.