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.
Related
I'm trying to figure out what the latest best practice is when it comes to REST APIs and finding an elegant way to "tell" the client what the response will look like. I'm no web expert. But I just recently joined a new team and I've noticed that in the client code, they have hardcoded URI to APIs... and anytime the schema of the return data changes, they have to patch their client code.
Trying to find a way to make things more dynamic by:
introducing patterns to "discover" API servers.
looking into HATEOAS.
More than anything else though, what I'm trying improve is having to change the client code each time the logic on the server changes as far as the body of a GET response.
I've been reading this:
https://www.programmableweb.com/news/rest-api-design-put-type-content-type/2011/11/18
And in particular, the following comments stood out to me: (under the WRML heading)
this media type communicates, directly to clients, distinct and
complementary bits of information regarding the content of a message.
The Web Resource Modeling Language (WRML, www.wrml.org) provides this
"pluggable" media type to give rich web applications direct access to
structural information and format serialization code. The media type's
self-descriptive and pluggable design reduces the need for information
to be communicated out-of-band and then hard-coded by client
developers
Questions
is WRML still a thing? this book that i'm reading is from 2011... and I'm assuming a lot has changed since then.
Can I cheaply build my own inhouse solution where we use the Content-Type or some other header to provide the clients with schema information?
can you point me to an example / sample code where someone is using custom values in Content-Type or other Headers to accomplish something similar?
Or if you have any other suggestions I'm all ears.
Thank you.
I don't know much about WRML, but I would look into:
HATEOAS formats like HAL/HAL Forms and Siren, which are self-describing.
JSON-Schema to describe responses and requests (and yes they can be linked from HATEOAS responses).
If you don't want to go the hypermedia route, OpenAPI and RAML
I've been developing Ketting for the last 5 years and HATEOAS has been nothing short of magic lately as all the tools have been falling into place.
Could anybody clarify the process of consuming aspx webservices in iOS? I have already tried JSON framework but now, need to create an app that consumes .net webservices in XML format. I need both to post some data to, and get data from the server. I already read about existing XML parsers for iOS that I found (here)
The question is do I need to do additional setup, like wrapping my query strings in SOAP or smth, in order to communicate with webserver? Would it be sufficient to use only one of mentioned libraries in the link or do I need additional stuff?
UPDATE: I found one tutorial on web (here) that demonstrates how to consume web services using Json-framework. Also, I found another one that demonstrates it using NSXMLParser (here). I'm not not very familiar with WSDL and SOAP, so any detailed explanation on how to implement would be desirable :). In both of these examples you just have to construct a request string in xml format and execute it, and that's it. Both examples actually bypasses the heavyness of SOAP and WSDL, so I was wondering do I have to know and do more that just construct a request string, execute it and get response?
While wsdl2objc is out there (as noted by #Girish Kolari), the truth is that there's no easy answer. I've never successfully gotten wsdl2objc working well for something that I couldn't have done more easily by hand. You will need to learn SOAP and WSDL. That's just a fact of life if you can't get access to a REST interface. In my experience, your best bet for simple SOAP access is to do it by hand, and your best bet for somewhat complicated SOAP access is gSOAP. Your best bet for very complicated access is to redesign something so it's not so complicated, ideally in REST. SOAP is a giant pain that some languages (C#) shield you from. ObjC does not shield you from it, so it continues to be a giant pain.
Yes, SOAP leaves a bad taste in my mouth.
If a iphone app needs to communicate with a server, is xml the best route in most cases?
how hard is it to parse xml in obj-c?
It really depends on the type of data you wish to exchange, but XML will at the very least be able to handle any complexity of data structure you require. (If you only want to exchange a minimal amount of information, you might want to consider JSON that said.)
There are quite a few XML parsers available for Objective-C, most of which are discussed on this existing question: Navigating XML from Objective-C
Finally, there's a great blog post on Ray Wenderlich's web site that discusses the various XML parsers with a view to speed/memory footprint which might be important if you're parsing a large amount of data.
Depends on what is beeing transmitted.
That said I use JSON for 90% of my server to app communication. Easy to parse as libraries are readily available.
Nope. Not hard. But when it comes to APIs it seems many prefer JSON.
JSON is easier to work with than XML, regardless of parser used. Lots of server side people will understand JSON quite well because of the need to use it to work with Javascript.
The iPhone JSON parser I'd look at using first is YAJL.
I would either go with XML or JSON ( http://www.json.org/ ).
It's very easy to parse XML on the iPhone. There are quite a few XML parsers out there based on your preference. For a DOM parser you can use TBXML, otherwise Apple's built-in NSXMLParser does the job.
I use JSON, which is a great (and popular) solution for your server as well. Try out SBJSON for a good obj c library:
http://code.google.com/p/json-framework/
We are going to set up a solution where the iPhone is requesting data from the server. We have the option to decide what kind of solution to put in place and we are not sure about which way to go.
Regarding SOAP I think I have the answer, there are no really stable solution for doing this (I know there are solutions, but I want something stable).
How about REST?
Or is it better to just create our own XML? It's not going to be so complicated reguest/respons-flow.
Thanks in advance!
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!
REST is the way to go. There are SOAP solutions, but given that all people end up doing with SOAP can be done with RESTful services anyway, there's simply no need for the overhead (SOAP calls wrap XML for data inside of an XML envelope which must also be parsed).
The thing that makes REST as an approach great is that it makes full use of the HTTP protocol, not just for fetching data but also posting (creating) or deleting things too. HTTP has standard messages defined for problems with all those things, and a decent authentication model to boot.
Since REST is just HTTP calls, you can choose what method of data transfer best meets your needs. You could send/receive XML if you like, though JSON is easier to parse and is smaller to send. Plists are another popular format since you can send richer datatypes across and it's slightly more structured than JSON, although from the server side you generally have to find libraries to create it.
Many people use JSON but beware that it's very finicky about parsing - mess up a character at the start of a line, or accidentally get strings in there without escaping "'" characters and there can be issues.
XML Property-lists (plist) are also a common way to serialize data in Cocoa. It is also trivial to generate from other languages and some good libraries exist out there.
You are not saying how complex your data structures are and if you actually need state handling.
If you want to keep your network traffic to a minimum, while still keeping some of the structured features of XML, you might have a look at JSON. It is a very light weight data encapsulation framework.
There are some implementations available for iPhone, for instance TouchJSON
Claus
I would go with simple HTTP. NSURLConnection in the Cocoa libraries make this pretty simple. Google Toolbox for Mac also has several classes to help parsing URL-encoded data.
I think it's obvious that REST is the new king of servers communication, you should definitely use REST, the questions should be what REST methodology you should use and what coding language, in my post I present few very simple implementations for REST servers in C#, PHP, Java and node.js.
I have a fair bit of experience working with the iPhone SDK. I have a couple fully developed apps including a utility application for tracking data and a board game. I would consider myself a novice on the iPhone SDK. I also have no issues with reviewing documentation and examples for hours until I understand something, as long as the documentation exists and makes sense.
I am not however an expert at XML documents and parsing attributes and creating documents. I have written in the past PHP code to access web services and complete transactions via SOAP XML messaging. I need to do a similar application using iPhone SDK. Here is what I need.
1) Create XML messages to send to a SOAP service
2) Receive XML messages from a SOAP service
3) Parse the XML response messages into a custom object
All of the URL and SOAP part is relatively straight forward. Where I start to get discouraged is the area of creating and parsing the XML messages. Using PHP these tasks are very simple as the language has built in SOAP clients and you can easily class map objects to SOAP messaging and the heavy lifting of the XML processing is just taken care of automatically. I have considered writing a proxy PHP service and simplifying what is needed on the iPhone side but this just complicates what I want and adds a dependency on another app to work in conjunction with the web service I'm accessing.
It seems that in the iPhone SDK or objective-c in general you have to be a pro at the construction and the parsing of XML messages on your own. I am really discouraged at the idea of creating tons of custom code to parse each message element by element. I've taken a small look at TouchXML / KissXML and I am not thinking they are what I need.
The real key objective here is that I want to easily receive an XML message and some how get the elements and their values copied over to an object. How can this be done without hours of writing parsing classes and understanding all of the guts of creating XML documents?
I have used Matt Gallagher's XPathQuery to great success on the iPhone. It's simple and straight-forward.
I've found, though, that the messages I have need to parse are drastically simpler than what XML (and even his simplified parser) is capable of. I've modified his source to return a data structure that's much easier to work with -- instead of having keys a bunch of keys (nodeName, nodeContent, nodeAttributeArray, attributeName, ...) for each node, I simply create nested arrays and dictionaries with the node name as the key and the content as the object directly. I completely ignore attributes, and I only use arrays if there's more than one node with the same name. Here's that code. Note that it's only been tested on the XML that I care to work with. :)
Edit: whoops, I just realized you're also looking for XML creation. This just does parsing. I'll leave it here as a partial answer.
It seems like what you really want is this:
http://code.google.com/p/wsdl2objc/
As it will create objects for you from a WSDL, and provide support code to send/receive them.
However what is mostly happening, is that people are not using SOAP for mobile web services, but instead are going to RESTFUL approaches.
That includes posting form data in HTTP POST requests or querying via GET, then getting back either JSON or plists which turn into dictionaries (JSON is more widely understood by server developers BUT you have to be more careful to correctly define the structures being passed, since you can do things like have a dictionary with the same key repeated... plists are more robust in that you can't really build anything "wrong" but is less standard on the server side).
If you have to use SOAP though, WSDL2ObjC is probably going to save you a lot of mapping.