How to upload binary file(Photos etc ) with Meta Data using REST - rest

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.

Related

why Fiddler4 not support Content-Type 'application/x-protobuf'?

Both request/response not showing proper formatted text
Image show info on fiddler
example x-protobuf data not showing proper formatted
example x-protobuf data not showing proper formatted
Fiddler do not has no support for Protobuf encoded messages. If you want't to know why that can't be answered here - contact Telerik and ask them.
There is an old plugin for Fiddler named ProtoMiddler that extends Fiddler to have some basic protobuf support, however it is quite complicated to install as it relies on protobuf installed (AFAIR the old protobuf v2) into a certain absolute path and the plugin has not been updated for years.
If you really need a Proxy with good Protobuf support I can only recommend Charles proxy to you. It allows to view protobuf messages RAW as well as decoded using compiled protobuf definitions (can be loaded/updated at run-time). Furthermore you can assign protobuf definitions to certain request and/or response paths.
From what I know, Fiddler doesn't support Protobuf.
If you need the see qualified Protobuf content, you need a schema that generates a protobuf binary.
You can try out Charles Proxy or Proxyman. They both support Protobuf parser pretty well.

Transfering multiple files and meta data in POST request

I've got a Python Django Backend running, and want to design a microservice. This microservices has a rest POST endpoint open. Now I want to transfer multiple binary files and some meta data (as json?) in a single POST request from Django to the microservice. What would be the besteht way to accomplish this.
I thought about transfering the data as multipart, but I think it's Mord for HTML forms. Also thought about protobuf. Would appreciate if you could help me, what's the most common way for such problems? What's the most efficient way?
It shouldn't be important, that I am using Django or Python for the answer.
The simplest solution is to use multipart/form-data. This is supported (as in builin) by all web application servers and almost web clients. It supports multiple arbitrary binary files and other data in the same request.
So my answer is KISS.
P.S. It is not only for forms.

Mime Type of Partially Uploaded File

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.

How SOAP and REST work with XML/JSON response?

This is one very common question asked again and again on stack overflow and I read so many answers about this but I am still bit confused.
I need to call the webservices from iPhone sdk.
Here are my questions:
I am not clear what response SOAP or REST return.Is there anything specific that if response is XML then we should use REST and if JSON we should use SOAP?
What is the role of ASIHTTP with SOAP and REST?
If I am getting XML response as
<oproduct>
<iid>113133791</iid>
<icategoryid>270</icategoryid>
<imerchantid>1547</imerchantid>
<iadult>0</iadult>
<sname>The Ashes / 1st Test - England v Australia - Day 1</sname>
<sawdeeplink>http://www.acbcd.com/pclick.php?p=113133791&a=111402&m=1547&platform=cs</sawdeeplink>
<sawthumburl>http://images.abcdd.com/thumb/1547/113133791.jpg</sawthumburl>
<fprice>69.99</fprice>
</oproduct>
Do I need to parse it by hand? or how do I handle XML response?
I got so many articles about REST and SOAP but no proper code to understand it.
I would be grateful for any help regarding these questions.
SOAP - "Simple Object Access Protocol"
SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).
So SOAP has a standard how a message has to be sent.
Each soap web service can be defined with a WSDL(Web Service Definition Language) which is kind of a schema for the SOAP XML transferred.
There are many tools available to convert WSDL(your webservice definition) to native code.
One of the tool available for ObjC is Sudz-C (http://sudzc.com/) which convert the WDSL of any webservice to ObjC code to access the Web service.
Rest - Representational state transfer
Rest is a simple way of sending and receiving data between client and server and it don't have any much standards defined , You can send and receive data as JSON,XML or even a Text. Its Light weighted compared to SOAP.
To handle Rest in iOS there are many tools available, I would recommend RestKit http://restkit.org/, for handling XML and JSON both.
I would suggest you to go with Rest for mobile development, since its light weight
(Simple example, People correct me If I am wrong)
Ok, so you have a few different questions here:
REST is a way of accessing the web service. SOAP is an alternative way of accessing the web service. REST uses query string or URL format whereas SOAP uses XML. JSON and XML are two different ways of sending back data. SOAP and XML are usually associated with each other. For mobile apps, REST/JSON is usually the way to go. Easier to implement and maintain, far more telegraphic, etc.
ASIHTTP, as Bill notes, is a wrapper. There are other choices that do similar things depending on what you need. If you are using REST/JSON then NSURLConnection + SBJSON might do the trick, I like it personally.
If your SOAP service has an available WSDL you can use wsdl2objc to automatically build the code for your parsing and fetching. If it is a JSON service or no WSDL is available, I would recommend using SBJSON and simply parsing in the following way:
for (id jsonElement in repsonse) {
self.propertyA = [jsonElement valueForKey:#"keyA"];
self.propertyB = [jsonElement valueForKey:#"keyB"];
}
Hope that helps!
1) SOAP responses must be XML, and to return other formats you need to either embed them in the response XML (inefficient) or use SOAP attachments (difficult). SOAP responses are contained in a soap envelope tag, and there is usually an associated wsdl. If the XML you show is all you're getting, then it may not be a SOAP service. I see links in the XML so that is a good sign that they had REST in mind.
2) I haven't heard of ASIHTTP. A quick google, and it looks like its a third party library that wraps the http interfaces in iOS. It looks like you would use that to help you make the http requests, although I would suggest that it might not be necessary; you should evaluate using the http libraries directly.
3) You need to parse it somehow. You can do it by hand, but that is generally a really bad idea. XML can come in many forms and still have the same meaning, and if you don't support all forms your application could break in the future if the web service provider began to format their XML differently, even if its semantics were the same. You would use an XML api to read the XML. The DOM api will read it into a tree form for you, and you can use XPath to extract information out of the tree.

REST vs. SOAP for large amount of data with Security

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.