I wanted to know if JSON is still used in live applications? I am creating a service and want to understand if I should output data using JSON too?
What is the latest standard now?
JSON is very popular, and there is no sign that this is changing.
I am creating a service and want to understand if I should output data using JSON too?
You really need to ask the potential customers of the service that question. Or at least, give us some hint as to what the service is and what clients are likely to use it.
What is the latest standard now?
There is no official standard for JSON. In theory, JSON is a subset of ECMAScript (aka JavaScript), so the relevant ECMAScript standard would be normative.
In practice, JSON is implemented in many languages independently of ECMAScript. The description on the JSON.org website, and IETF RFC 4627 are probably the most relevant to someone implementing JSON for themselves, but neither of these sources have the authority of a standard. If you want JSON libraries, the JSON.org site is a good place to start looking.
Yes, JSON is still very popular. Even Google web services API gives search output in JSON.
Take a look at this example:
http://zamples.com/JspExplorer/samples/google.jsp
Overwhelmingly yes. For me, JSON is the transport format of choice for AJAX requests and inter-application data sharing. To date, there are 1271 questions about JSON on SO.
Related
I've a home-made php based web calendar which I would like my users to import into Google Calendar, iCal, etc. so they have up-to-date information available on their calendar of choice. I understand providing a webcal link is the way to go but I am not sure how to create it. I've donwloaded an example .ics file but did not have much info..
Where can I find more info on creating a webcal feed? Also, does webcal allow authentication? The feed will most likely be password protected.
Thanks!
A webcal feed use iCalendar format as defined in RFC 5545. It's a rather complex and cumbersome format. You'll find simple examples on wikipedia which may fit your needs. You could also opt to use a library to abstract the format, such as:
http://framework.zend.com/svn/framework/laboratory/Zend_Ical/
http://bennu.sourceforge.net/
http://sourceforge.net/projects/icalcreator/
http://sabre.io/vobject/
From all of these the last one might be your best bet (all others seemed to be dead last time I checked).
As for authentication you may use basic HTTP authentication. Or use a secret token to identify the user (as seen in Google Calendar). Anyway, in both cases you probably should use secure connection (SSL) so data (and passwords) are not sent in clear.
And finally I would recommend the use of webcal:// or webcals:// scheme for ease of use for end-user. But you may face troubles with some clients (eg: Outlook 2007 and forced SSL). I don't have a work-for-all solution yet...
EDIT
I forgot to mention the ICS validator in case you don't use a lib .
I have a small RIA that I built as a learning/make-my-life-easier project that uses Flex and ASP.Net. Currently, my architecture utilizes straight HTTP posts and the server responds with xml. I posted another question about security in my web app and some people mentioned SOAP. SOAP is something I've never actually used and I was wondering what the pros/cons were to using SOAP over my current architecture and then subsequently, how much work is require to convert such an application to utilize SOAP.
Thanks,
Chris
Since you have already implemented your own message schemas for sending and receiving, then SOAP in of itself will not give you any added value. The added value comes from SOAP's support for the WS-* standards, covering security, transactions, and several other goodies. The recommended way to take advantage of all that is to use WCF rather than ASP.NET, because WCF supports the latest versions of those standards.
FYI when trying to use SOAP with FLEX - XMLDecoder in Flex does not currently decode some complex data types appropriately, making it appear that you are not receiving all data. I have tracked the error down to the XMLDecoder where I can see the correct data is received, but is not appropriately packaged in the ResultEvent requiring me to override the XMLDecoder, which, I am sure you can imagine, is not very fun. Just wanted to put in my 2 cents. If you are thinking of moving in that direction it would probably be nice to know it doesn't always work for very complicated data types (in my example a collection of objects containing 2 strings and 2 arrays - only returns a collection of 1 string). Granted, it does work 99% of the time, but not always.
So.. I set up IE to use WebScarab as a proxy, and then logged into Quality Center. Lo and behold, the program uses HTTP to do all its communication with the server, and the all commands and responses are human-readable text. It ain't XML, it ain't JSON, but its human-readable and I'm pretty sure I could write it if I had to.
So.. is this protocol documented anywhere? Are you "supposed" to be able to use this? Anybody have any experience using it anyway?
And yes I am aware that they have a COM api, but I have a feeling that the crashy behavior I normally experience from QC is probably in the COM objects, so any software I might write that uses them would exhibit the same behavior.
The officially supported method for communicating with QC is via the published Open Test Architecture (OTA) API which is very well documented. I think you would have your work cut-out trying to re-write the API at a lower HTTP level. Lots of people are using the OTA API successfully to customise QC and write third-party extensions. Also many of the COM idiosyncrasies are now documented on the .NET. Maybe you can elaborate on the sorts of problems you are having with the COM API?
The below page can help :
Visit
http://technologicaguru.blogspot.com/2009/06/connect-to-quality-center-ota-client.html
Looking around, I can't name a single web application (not web service) that uses anything besides GET and POST requests. Is there a specific reason for this? Do some browsers (or servers) not support any other types of requests? Or is this only for historical reasons? I'd like to make use of PUT and DELETE requests to make my life a little easier on the server-side, but I'm reluctant to because no one else does.
Actually a fair amount of people use PUT and DELETE, mostly for non-browser APIs. Some examples are the Atom Publishing Protocol and the Google Data APIs:
http://www.ietf.org/rfc/rfc5023.txt
http://code.google.com/apis/gdata/docs/2.0/basics.html
Beyond that, you don't see PUT/DELETE in common usage because most browsers don't support PUT and DELETE through Forms. HTML5 seems to be fixing this:
http://www.w3.org/TR/html5/forms.html#form-submission-0
The way it works for browser applications is: people design RESTful applications with PUT and DELETE in mind, then "tunnel" those requests through POSTs from the browser. For example, see this SO question on how Ruby on Rails accomplishes this using hidden fields:
How can I emulate PUT/DELETE for Rails and GWT?
So, you wouldn't be on your own designing your application with the larger set of HTTP verbs in mind.
EDIT: By the way, if you're curious about why PUT/DELETE are missing from browser based form posts, it turns out there's no real good technical reason. Reading around this thread on the rest-discuss mailing list, especially Roy Fielding's comments, is interesting for some context:
http://tech.groups.yahoo.com/group/rest-discuss/message/9620?threaded=1&var=1&l=1&p=13
EDIT: There are some comments on whether AJAX libraries support all the methods. It does come down to the actual browser implementation of XMLHttpRequest. I thought someone might find this link handy, which tests your browser to see how compliant the HttpRequest object is with various HTTP options.
http://www.mnot.net/javascript/xmlhttprequest/
Unfortunately, I don't know of a reference which collects these results.
Quite simply, the HTML 4.01 form element only allows the values "POST" and "GET" in its method attribute
Some proxy servers with tough security policies might drop them. I'm using PUT and DELETE anyways.
I've read that some browsers do not support other HTTP methods properly, though I can't name any specifics.
Rails, in particular, will pack your forms with a method parameter to explicitly set this even if the browser doesn't support those methods. That seems like a reasonable precaution if you're going to do this.
I say use all the features of HTTP, browsers be damned, lol. Maybe it'll inspire more complete and proper use of the HTTP protocol moving forward. There's more happening on the net than just POSTs and GETs. About time browser implementations reflected this.
This depends on your browser and Ajax library. For example jQuery supports all HTTP methods even though the browser may not. See for example the jQuery "ajax" documentation on the "type" attribute.
The Restlet Java framework lets you tunnel PUT and DELETE requests through HTML POST operations. To do this, you just add method=put or method=delete to your URI's query string, eg:
http://www.example.com/user=xyz?method=delete ...
This is the same as Ruby on Rails' approach (as described by #ars above).
Personally, I really don't see any purpose for using PUT or DELETE in a web application. All operations that an application performs are read or write, aka input output. Why do you need to distinguish the nature of the operation in the header of the HTTP request?
I could make ajax calls with the same url of form /object/object_id
and do multiple operations like delete, update, get the value, or create.
Just by looking at the URL, I have no clue which one it is.
By using GET and POST only, my urls will be:
/object/id/delete
/object/id/create
/object/id/update
/object/id --> implied GET
etc.
Based on my limited experience, this is a lot cleaner than hidden header request types in many cases.
I am not saying one should never use PUT or DELETE, just saying, use them only if absolutely needed.
Refer to "RESTful Web API" by Leonard Richardson to read more about different use cases and conventions regarding HTTP request methods in a RESTful web api.
When I talk to an developer from the Microsoft ASP.NET world and he uses the word "Webservice", does that word in every case imply a specific data format (XML? SOAP?)?
Or is it just anything you can call via http(s)?
In my view, it can be anything that's over http/https, and intended for calling by an application rather than a user's browser.
In particular, REST and SOAP are quite different about how they pass arguments in and get results back
The term Webservice itself is language-agnostic.
This is a decent overview.
If an Asp.Net developer says WebService, you can pretty much bet that they are talking about XML/SOAP.
However this is not universally true. I think it's just fine to call anything a WebService if 1) the data source is available via the web or 2) it is a web address that can provide back information given a set of inputs.
For example, StackOverflow.com allows for screen scraping of the User pages in order for 3rd party applications to be built. It's not specifically XML/SOAP but I would consider it a Web Service (format #1)
In my experience this completly depends upon who you are talking to. For some ASP.Net developers this is only SOAP for others it includes other things like REST. If you are planning on using the term in a specification it would be a good idea to be a bit more specific.
I can only agree with Paul, anything queried over the web, using the http(s) protocol and not browser oriented. But any web service should also have the functionality of being discovered (WDSL and so on).
Personally I mean any HTTPHandler!
That means under ASP.NET, a page is a webservice that returns HTML.
WCF extends that concept, because by default, WCF service requests in ASP.NET are processed by Modules not Handlers.
So really any web request is a service.
Typically though ASP.NET developers will be refering to SOAP unless they prefix i.e. WCF Webservices,