REST web services vs JSON services

Question

REST webservices imply the server-side is stateless (for the most part) and urls correspond to resources and HTTP GET/POST/DELETE/PUT methods correspond to operations on those resources.

I am planning to work on a JSON services layer that is dependent on server-side state, having urls that correspond to resources and having urls like /add /update /delete corresponding to different operations and all of those urls using HTTP POST.

1. What is the right terminology for this? Should this be called JSON web services? Is there any specific term for this?
2. It looks like Jersey+JAX-RS would be very useful for this purpose. Is it ok?
3. Would it make sense to use Struts for this kind of application?

Answer 1

1. JSON is a file format which your rest service may (or may not) use to send its answers. If you use this format to communicate with your webservice, you cann say that your service is a JSON web service.
2. Indeed, Jersey is a good JAX-RS implementation. However it is not the only one.
3. If you need a webapp to interact with the webservice you can use Struts. However, you can use any other tool (included some more recent technology, struts is really old) for the front-end of your system.

Answer 2

Well, it's not REST. However trying to defeat that tide of general misunderstanding just isn't going to happen.

What you are describing is actually what most of the world views as REST and therefor should be mostly OK with just calling it as such.

In the presence of a true Restifarian, you will get some push-back because they will be correct - however, there isn't really much need to add a tremendous amount of confusion to your daily life as the distinctions (and the MASSIVE benefits they afford...) are largely lost on anyone you work with.

(1) is accurate enough, or simply rest. (2) is redundant but it is a good framework for the technology. (3) I would say no, but noticing when this question was asked, I'm sure you already decided.