I have a web site witch using Angularjs to connect to An api written in php to get data and perform action and ths api send a json result. in checking site performance I found that my server response is very lass than downloading response from the web!!!
how can I change json property name by shorter aliases? for example:
{
"name": "test",
"family": "testi"
}
must be converted to:
{
"n": "test",
"f": "testi"
}
indeed in 2nd form of response content length is much shorter if my response contain an array of object.
is there any technology for client and server side for this issue? or is there any other solution?
We can compress our response by GZIP. also there is some high-performance serialization protocol like Protobuff or Thrift those are fast and secure but I think they are server to server solutions and using them in front-end area can not be a very efficient solution. also, We can create some mapping that can map our minimized property names in back-end DTOs to our front-end data models.
They are the solutions founded in my explorations and experiences. Any new suggestions are welcomed;
Related
For a few weeks, I've been trying to gather as much information on implementation of RESTful apis in PHP as I can but in vain. All the information that is given online only explain the most basic concepts but never did I come across a very real example with complete code on how RESTapi actually works.
For Example, POST is used create a new resource. But how? How is it implemented in real life? How do I do this in cURL? I am aware of the complete basics but am unable to find any concrete and complete example that explains everything. Most of the tutorials simply name the functions they've used but did not bother explaining what is happening exactly, what the flow of the program is, etc.
If someone can help with a complete example (say, a library registration and database) I'll really appreciate it. I'm really confused.
I will describe POST method in REST.
Client send HTTP request via POST method with JSON data.
For example, client send some data to create a word "nice".
POST http://localhost/word/1
JSON content
{
"data": {
"type": "word",
"attributes": {
"word": "nice"
}
}
}
In PHP you need get a response and convert to array and insert ot DB. Why insert? Because request method is POST.
I want to make a small PHP script that will check a web app periodically. The communication will be only in json. The code will run on Google App Engine.
First request will be an HTTP POST request with form data like this: username=user&password=pass
POST http://www.example.com/login HTTP/1.1
If login fails the response json will be:
{
"message": "Failed login"
}
If successful:
{
"response": "OK",
"username": "user",
"protocol": "http"
}
Subsequent requests will be GET, POST and PUT requests containing json and also the response will be in json.
This code will be run by Google App Engine's Cron for PHP ones a day.
Since I have little knowledge of PHP, I would like to know how I should implement this.
How do I make the http request to the web app.
How do I remember login/authentication headers from one request to another.
How do I handle reading, writing and modifying of json in PHP.
All I need is a basic example and guidelines to get me started.
Thank you in advance.
Tase
Given that GAE does not currently support cURL I would recommend an approach like How do I send a POST request with PHP?. Down the road you may be able to use something slick like Guzzle (if GAE adds cURL support).
Use json_decode/json_encode to create JSON to send and parse the responses.
Just to get you started: cURL and json_decode/json_encode.
If all of your requests will be in the same script, run all at the same time, you'll just need to use the cookies and headers options for cURL.
I'll leave a full example to someone else, if necessary.
Also, you should use HTTPS if possible. It's never a good idea to send username/password in clear text, no matter how trivial the service.
Edit: as it looks like GAE doesn't support curl (thanks #boombatower), check this out: Replacing CURL with urlfetch in PHP
I am working on a project where I am trying to expose the function of the software. Basically I have my backend set up and was thinking of seperating the frontend from the backend code using JSON msgs. I am a little bit confused as to what is the difference between a service and an API. I know API can be build on top on services. But I have these two models in mind -- to access profile X using json-rpc
http://xyz.com/?request={"jsonrpc":"2.0","id":1,"method":"getProfile","params":{"id":"X"}}
or should it be like this using REST -
http://api.xyz.com/X
Thank You
"Service" vs "API" is a pretty vague question. Often, the two terms are used interchangeably. "REST" vs "RPC" is a little easier to explain.
Usually with REST, a URL represents a specific resource such as a "user", an "account", etc.. Typically, you can create/retrieve/update/delete these resources by using the HTTP methods POST/GET/PUT/DELETE. To update the profile for user 1125 you might send the following:
POST /user/1125 HTTP/1.1
Host: wherever.com
Content-type: application/x-www-form-urlencoded
firstName=Davey&lastName=Jones&email=dj%40thebrineydeep.com
Anything you wanted to do with user 1125, you would send a request to the same URL. There are exceptions and variants of this idea, but that's the crux of it.
RPC services is more like just using a function library, which is bound to a specific URL. You might have a whole bunch of related functions all bound to the URL /services/json. Then if you wanted to change the profile for old Davey Jones, you would:
POST /services/json HTTP/1.1
Host: wherever.com
Content-type: application/json
{ "jsonrpc": "2.0",
"id": 1,
"method": "setProfile",
"params": [ 1125,
{ "firstName": "Davey",
"lastName": "Jones",
"email": "dj#thebrineydeep.com"
}
]
}
I personally like JSON-RPC better because:
I don't have to try and fit all of my function calls into some kind of resource-to-url mapping that might not make sense
We don't try to overload the HTTP response codes to indicate API errors. Every request returns a 200 response (unless there is a server error) and you know from the response body whether you got an error or not. JSON-RPC is particularly good at being explicit about error conditions.
Sometimes REST is better because:
Sometimes the resource-to-URL mapping fits really well
It is more intuitive for third parties to understand
It offers a simpler model for just retrieving easily-identified information
I don't think either one is any easier to code.
Edit I changed the REST example to use the more common form-encoded data instead of JSON. But of course you can specify any data format you like with REST. It isn't carved in stone.
Your REST URL does not equal your JSON-RPC request.
At least it should be http://api.example.org/getProfile?id=X
There really is not much difference between the two. And your "REST" isn't a real REST unless you return a data format that reliably can express links to different URLs, e.g. XML or (X)HTML. Until this requirement is met, you should only call it "RESTful", because you really only use HTTP methods to trigger stuff and move data back and forth.
It doesn't really matter what you use - unless you know or have experience with software that supports you building one or the other solution more rapidly than the other.
I've been reading a few REST tutorials and some of them says that in order to send data to a rest API you should send post data as an array, which is something like this:
$data = array('foo' => 'bar');
$rest->post($data);
Then there are others that say you should send JSON data like this:
$data = array('foo' => 'bar');
$data = json_encode($data);
$rest->post($data);
Not sure if there's a standard way of doing this or either if is fine but what is generally recommended when designing API's?
EDIT: There seems to be confusion. To clarify I agree JSON should be used for client consumption but this question is about SERVER consumption. Meaning should the SERVER accept JSON or POST data from its clients?
If you're the one creating the RESTful API, meaning your application is the server and is accepting requests, then your question seems confusing. Your application will not be sending any POST data; clients will be sending POST data to you.
With that being said, having an API which will accept JSON-encoded requests is possible, though would really only be useful for very niche scenarios. The vast majority of clients will be POSTing data to your API in the application/x-www-form-urlencoded format. PHP handles this behind the scenes for you, and exposes the data as the $_POST superglobal.
If you're talking about responding to POST requests, and what format you should use, then that will depend on what format the client wants you to send it in. The client will either specify this in the Accept header, or some APIs allow it to be specified in the URL (e.g. foo.com/some/thing/123.json or foo.com/some/thing/123/json). The client isn't required to tell your application what format it wants, so it's up to you to pick a sensible default. Most APIs will use JSON these days.
I've never heard of an API that understood serialized PHP array format, though, so I don't know what resources you've been reading, but I'm pretty sure you misunderstood what they were suggesting.
Actually, I think this is a pretty good question. don't know why it got downvoted.
Also, contrary to what I saw written in some comments, the client can use any language he wants, not only javascript. And it's not the server job to know which language was used to "build" the request, just that the request is valid. This makes more sense if you think that the entity making the request can actually be another server (think about a proxy server used to send post requests across domains).
That being said, personally, I think it's better for the server side to consume a XML or JSON. The main reason is validation.
It's easier to validate a XML or JSON against a schema.
Also the schema can be made public, and a well designed schema can describe webservice by itself. The client can even use the same schema to validate the request prior to sending it to the server.
Passing an url encoded form is also valid, of course. And can be validated server side as well. SO i think, down the road, it's just a matter of preference.
Also, check this discussion in SO, it regards the same topic:
JSON vs Form POST
You should think about the clients that will consume the API. A HTML5\AJAX client will probably want JSON data, while other clients (Silverlight or native mobile apps) might be better at consuming XML.
One great framework\platform for writing REST API's is looking to be Microsoft's Web API (based on ASP.NET MVC). The product succeeds the WCF framework and allows users to write REST API's in a MVC environment. One feature is that it chooses a serialization provider based on the HTTP Accept header.
So if a client Accepts application/json they work with the service in JSON and if the accept XML they work with the service in XML. You can also write your own object serializer and plug it into the framework.
More information: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/video-your-first-web-api
Most of the time you would want to stick to receiving POST data but I think receiving json data does have its uses for example when it comes to batch requests.
The Facebook API uses it.
You don't need to do file_get_contents('php//input'). From the facebook documentation you could just do something like this:
curl -X POST "http://example.com/batch" -d 'batch={ "param" : 1, "param2" : "2"}'
Then in the PHP code, if you're using PHP, you can get it through the $_POST parameter and do a json_decode.
var_dump($_POST);
array(1) {
["batch"]=>
string(30) "{ "param" : 1, "param2" : "2"}"
}
var_dump(json_decode($_POST['batch'], true));
array(2) {
["param"]=>
int(1)
["param2"]=>
string(1) "2"
}
JSON makes more sense, since it is language-independent and can be useful when API scales.
I am currently developing a REST API and I was asking myself the same question. After some research I found out that is no standard and is totally up to you.
You are developing the server side so you can decide how data should be sent to you. The client need to adapt to your design.
Personally I choose to receive all POST and PUT data as JSON directly in body.
The point is to reuse the HTTP implementation that already exists.
HTTP is built to accept many different content-types and you only need to specify which you are using in the headers.
A REST API that accepts the various formats and works off the content-type header is refreshing. You can submit x-www-form-urlencoded values from an HTML webpage or make an AJAX request with raw JSON and there is no confusion as long as everyone is following protocol.
As a developer you must choose the support your app will provide because you can't support everything. Typically it boils down to the support or convenience of your own environment -- nobody wants to reinvent the wheel.
Many frameworks that are designed with building APIs in mind, handle the most popular content types at a lower level. They may also encode the response data according to the "Accept" header.
Implement whatever you think will be used most first or find a framework that already speaks HTTP and takes care of all of that for you.
I'm new to iPhone app development so excuse me if I use the wrong terminology, or ask the wrong questions. Basically, I'm trying to write an App that includes downloading a dataset, saving it for later, and checking if the dataset has been updated, but I don't know where to begin.
When I say dataset, I mean a multi-dimensional array of key/value pairs.
I will be creating a site that my App will pull the data from. I think REST is the technology that it will be using (new to REST, too), being served up by a Zend Framework application, using MySQL as the back end database.
So the data will be stored in a MySQL database, and I need to be able to download chunks, which I assume will be stored in my App's SQLite database, to be accessed later (when internet access is not present). At some point in my application's life cycle, I want to check if the dataset that I have downloaded is the most recent version.
There are a lot of parts to this that I am still confused about. Can anyone please shed some light on any/all of the areas that I have touched upon. Is there any iPhone framework that I should be aware of that would make this process go faster/easier?
Thanks!
Update: Maybe I should break this up to make it easier to answer:
I am assuming that my API will retrieve the data from the database and output the response as XML. Is this the best/only option?
In my App, how can I make an API call?
How can I parse the response (probably XML) from an API call and store it for later retrieval?
A really cool technique I found for making web services that will only serve iPhones is to find a plist library for your framework. I usually use Django, and Python has a built-in plist library. This means you can turn your data into a plist object, rather than a standard XML file. This can be serialized and sent over the network just like a standard XML file, but you won't need to use NSXMLParser to parse the file.
From your app, you can make an API call by using the NSData object's method:
+ (id)dataWithContentsOfURL:(NSURL *)aURL
This method will create a data object with the contents of the URL, where the url specified is the address of your api. You can then turn that data object into a string, a dictionary, or whatever your root object in the plist file is.
In order to manage the updating, I usually use a waterlevel method. The iPhone stores the time that it last updated in something simple like NSUserDefaults, and the server stores the time of each entry or update in the database. On the api call, you should pass the server the last updated time as a GET or POST parameter. The server will then search it's database for things updated or entered since then, and send only these objects to the phone.
If just wanting to fetch (GET) data, a REST API call is simply a URL you go to that usually returns XML instead of HTML. Your URL could be www.site.com/rest/fetchstuff or www.site.com/dosomethigncool, doesn't matter. For the app to "call" the API, it'd connect to that URL and include whatever parameters then download the XML from the server.
Let's say your app finds cars for sale. The URL/REST API would be www.site.com/rest/cars/findAll. Your app would call this URL: www.site.com/rest/cars/findAll?make=jeep&model=wrangler. The server would search the database for all cars that are Jeep Wranglers then return the results formatted as XML. Your app would download that XML then parse it.
Check out the SeismicXML sample project. NSURLConnection is what connects to your REST API and downloads the data (XML). NSXMLParser can parse the XML you download.