I am using Play Framework version 2.2 and I am trying to get the mime type of a partially uploaded file so I can do a direct upload to an Amazon S3 instance. What is the best practice for doing this?
I am currently using FlowJS but it doesn't look like they have anything in particular for dealing with mime types. Additionally, I plan on making mobile apps that will use the same API so it would be best if it was on the server side and not the client side.
The only solution I can think of is parsing the extension and mapping that to a mime type, but that sounds like a hacky way to do it.
Related
One way of doing is to convert the binary data to Base64 and send it along with meta data as MediaType.APPLICATION_JSON.
The problem with this is client has to convert the binary data into Base64 before sending.
I also tried sending using MediaType.APPLICATION_OCTET_STREAM format through REST. This works fine for binary data only.
One option is to send meta data in headers while using MediaType.APPLICATION_OCTET_STREAM.
Is there any better way?
Thanks
Use multipart/form-data. This is what it's meant for. Not sure which Jersey version you are using, but here is the link for the Jersey 2.x documentation for Multipart support. Here's for 1.x (not really much information). You will need to do some searching for using multipart with Javascript clients (there is a bunch of information out there)
Here is a good example of using Jersey 2.x with both the server side and the client API.
Here is an example with Jersey 1.x. You can see the API it not much different.
I have a requirement where I have large amount of data(in form of pdf,images,doc files) on server which will be distributed to many users. I want to pull these file using web services along with their meta-data. I will be getting the files in bytes. I am confused in which type of web service will be more secure, easy to parse? Which one is easy to implement on iPhone client?
I know REST is simpler but I read somewhere that it is not suitable for distributed environment. At the same time SOAP is too heavy for mobile platform.
I have searched many sites describing how REST is easier and how SOAP is secure. I got confused about which one to use?
Also about the kind of response, which will be better JSON or XML for my requirement?
For your requirements JSON will be the best kind of response because it is way smaller than XML (More than 50% smaller in many tests). You can use SBJSON (https://github.com/stig/json-framework/) to parse it easily on iOS.
Concerning REST or SOAP, the last one is indeed really heavy for mobile platform and not so easy to implement. SOAP requires XML too and cannot be used with JSON. Whereas with REST you can use JSON or XML and easily implement it on iOS with RESTKit (http://restkit.org/), for security you can use an SSL connection with HTTPS and a signed certificate.
The only advantage of SOAP is the WSDL (Webservice specification) which made your webservices really strong.
Unless you have a specific requirement to pull the file data and the metadata in the same response, you might consider just pulling down the file with a regular HTTP GET. You can get decent security with HTTPS and Basic Auth or client certificates. I would then include a Link header pointing to the metadata for your file, as in:
Link: </path/to/metadata>;rel=meta
In particular, this lets you have separate caching semantics for the file itself and for its metadata, which is useful in the common case where the files are much larger than their metadata and where metadata can change without file contents changing.
I know it might sound silly but how do I determine a website supports JSON?
I know what/how JSON use for a long time, but I do not know how could I technically know whether a
server has json support. Do I need to manually request json file to check whether it suppports or not?
Any comment would be appreciated !
You can check what is the content type of server response, usually this is
application/json
(1) "Websites" don't really serve up JSON; the notation syntax isn't really meant for page rendering, it's made for data transmission.
(2) What oftentimes serves up JSON are APIs (like those of Facebook and StackExchange). These APIs usually use HTTP GET, POST, PUT, and DELETE methods to interact with services they provide, and (sometimes optionally) transmit the bulk of the payload data in JSON format.
(3) It doesn't really make sense to ask where to get JSON. If you'd simply like to play with some JSON for educational purposes, Python, PHP, Javascript, etc. all have great built-in support. What you ought to be looking for are the services that you'd like to utilize, and whether or not they support JSON. If the service is new, or popular, and has relatively good API support, odds are it will work with JSON.
As far as I know, JOSN is just a format, like XML. You can create JSON page by hand, or use easy functions in a lot of the major coding languages.
Example: PHP does this easily with json_encode(String) json_decode(String). So, as far as my knowledge goes, every server / website can support JSON, though some might not have the updated PHP or whatever coding language you may be doing, to support easy implementation of JSON.
I would like to build an XML over HTTP provisioning interface using Zend Framework. Should Zend_XmlRpc_Server be used for this purpose? If so, can you recommend any guides on using it? (Specifically the part retrieving incoming XML and parsing it.)
What kind of service is it? - will you send binary data or rather short texts? Will all clients be in PHP mostly or you are foreseeing a wide range of clients?
Usually if you're doing a web-based small service, REST will do the trick, it's easy to develop and consume, even by plain JS frontends, such as jQuery.
If it's something more complex, you can't go wrong with SOAP, though it's a bit complex in developing. Make sure you arm yourself with SoapUI
XmlRPC has some limitations, especially sending binary data. There's some thorough comparison to have a look at this blog
I'm writing a simple application that communicates with an external server.
The server currently supports yaml, xml and json.
Which encoding is fastest on IPhone?
Which has better support?
What libraries do you suggest?
I worked on a project that connected Motorola handsets running J2ME with a speech server in the network. We found that total bandwidth was worth optimizing (this was on a 2.5G network in 2004). So I'd suggest you measure how many bytes each serialization format takes and go with the smaller one (which will be JSON or YAML). You might even consider using a binary protocol like Hessian or Google's Protocol Buffers.
We also discovered that minimizing the number of messages decreased latency, so be on the lookout for ways to send data to the iPhone in fewer, larger chunks, use an HTTP cache on your phone, use HTTP entity tags and If-Modified headers, and so on. Since you're using REST, you're well positioned to leverage all these nice features of HTTP.
Of course this can all very easily be premature optimization, so code it up the easiest way possible and measure first.
I've created an open source application for iPhone OS 3.0 that shows how to use REST & SOAP services in iPhone application, using XML (using 8 different iPhone libraries), SOAP, JSON (using SBJSON and TouchJSON), YAML, Protocol Buffers (Google serialization format) and even CSV from a PHP sample app (included in the project).
http://github.com/akosma/iPhoneWebServicesClient
The project is modular enough to support many other formats and libraries in the future.
The following presentation in SlideShare shows my findings in terms of performance, ease of implementation and payload characteristics:
http://www.slideshare.net/akosma/web-services-3439269
Basically I've found, in my tests, that Binary Plists + REST + JSON and XML + the TBXML library are the "best" options (meaning: ease of implementation + speed of deserialization + lowest payload size).
In the Github project there's a "results" folder, with an Excel sheet summarizing the findings (and with all the raw data, too). You can launch the tests yourself, too, in 3G or wifi, and then have the results mailed to yourself for comparison and study.
Hope it helps!
Using json-framework, making your classes interoperate with JSON is ridiculously easy.
Well, if you want to use XML, use a plist, since its supported natively on the iphone.
JSON is not, but there are some good c libs available. I support JSON and XML in my app.
Same with XML - there's a bunch - just search around.
It also depends what media-types your server supports - btw, REST isn't really a protocol.
I have some benchmarks comparing the performance and payload sizes of the different serializers available here:
http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.1000000-times.2010-02-06.html
Basically, if you're developing with .NET web services than you are going to be making a compromise on payload size vs performance, unless you go with another serializer.
Marc's protobuf-net shows the smallest and fastest implementation:
6.72x faster and 4.68x times smaller than MS's fastest Xml Serializer; and
10.18x faster and 2.24x smaller than MS's JSON DataContract Serializer;
Although being a binary protocol, it may be harder to debug.
If your developing with MonoTouch (i.e. C#/Mono for the iPhone) and want to use a text-based format, than you may be interested in my Javascript-like type serializer that has been optimized for size and speed, it also shows modest gains over the available XML and JSON options, namely:
3.5x quicker and 2.6x smaller than the XML DataContract serializer; and
5.3x quicker and 1.3x smaller than the JSON DataContract serializer.
Here's a MonoTouch tutorial showing how to call web services from an iPhone:
http://www.servicestack.net/monotouch/remote-info/
IF you are ok with a c++ library in your iPhone projects, then please have a look at yaml-cpp:
http://code.google.com/p/yaml-cpp/
has native iPhone support (via it's cmake build system)
has no dependencies beyond a good compiler and cmake
is very c++ friendly (thus, the name) with solid documentation (see the wiki/HowToParseADocument page)
It really depends on your need and what kind of data you are going to transfer between server and application. If you want to execute queries to select some piece of data you should choose XML because of XQuery language support. JSON is not supported, as I know. I can nothing to say about YAML.
I have not seen any YAML libraries (though it does not mean there are none). I know TouchJSON works pretty well, and there is at least one other.
JSON takes less space than an XML or PLIST feed, BUT needs a little more thinking ahead of time to get the structure right.
One nice aspect of pLists is that you get back dates as objects without parsing. If you pass dates in a JSON decide on a format and use the same format everywhere. NSDateFormatter is not thread safe so you have to make an instance per thread, if you want to use a single date formatter to save resources.
there is support for all three formats in Objective-C. Just google for them. I would suggest writing a serializer that supports all three. Just make your URL resource request end with .xml|.json|.yaml and have the server decided what to serialize to based on that extension. Then you don't actually have to decide you can switch to whatever you want. Making the serializer pluggable is really easy in most server side implementations.