Should the WebDAV PROPFIND method be used with JSON in REST APIs?

Question

I'm building a web service that use JSON everywhere.

Now I need an HTTP method to retrieve properties of a resource (e.g. attribute like read-only, write, ACL, on so on). It looks like there is only one HTTP method for this purpose: PROPFIND.

However the spec clearly instructs to use XML.

Is that insane to use that verb with a JSON interface anyway? I'm also concerned that PROPFIND is part of the WebDAV extension.

If that's a no-go, what is the recommended verb or the recommended way to retrieve properties for a resource in a JSON-oriented web service?

Answer 1

In a "representational state transfer" architecture, the idea is:

• to use a very limited set of input/output verbs whose formal properties can be universally defined (e.g. GET and HEAD are safe, PUT and DELETE are idempotent),
• to circumvent this small number of verbs with an unlimited number of resources.

Therefore using other verbs than those that are defined in HTTP is a bad idea. As a matter of fact, every WebDAV verb could have been done with HTTP verbs (and the appropriate headers and resources).

In a RESTful world, you have several options:

• to define a new kind of resource for metadata,
• to mix data and metadata in the representation of the same resource,
• to manage metadata as HTTP headers (note that you can use the HEAD verb if you need to get metadata without the data).

Answer 2

REST is protocol independent but it's frequently implemented over the HTTP protocol. WebDAV is an extension of the HTTP protocol. So, in theory you could use WebDAV methods too (it doesn't mean you should).

From the chapter 6 of Fielding's dissertation:

6.3.1.2 Extensible Protocol Elements

[...] HTTP request semantics are signified by the request method name. Method extension is allowed whenever a standardizable set of semantics can be shared between client, server, and any intermediaries that may be between them. [...]

Keep things simple and stick to the standard HTTP methods: they are well-known and they are supported by a huge amount of clients and proxies.

See below a couple of approaches you can use to get metadata from your resources using HTTP verbs:

Using a sub-resource

You could have a metadata sub-resource for the resources you want to request some metadata. For example, to get the metadata of a user resource, it would be as simple as:

GET /api/users/johndoe/metadata HTTP/1.1
Host: example.com
Accept: application/json

Using a custom media type

Another approach you could consider is a custom media type such as application/vnd.company.metadata+json for representing the metadata of your resources. So, you would have something as following:

GET /api/users/johndoe HTTP/1.1
Host: example.com
Accept: application/vnd.company.metadata+json

With this approach, the same endpoint could support other media types such as application/json and/or application/vnd.company+json to return the data itself:

GET /api/users/johndoe HTTP/1.1
Host: example.com
Accept: application/json

GET /api/users/johndoe HTTP/1.1
Host: example.com
Accept: application/vnd.company+json

If you need, another media type such as application/vnd.company.full+json could be used to request both data and metadata of a resource:

GET /api/users/johndoe HTTP/1.1
Host: example.com
Accept: application/vnd.company.full+json`

A similar approach is used by the GitHub API.

Answer 3

When you trying to make HTTP web services surely there is also some method which you can use in HTTP headers. but also there is also many property attribute which contains the info regarding request/response like "status", "Content-Type" etc.

you can also set these property in your web services. like

"Content-Type": "application/json";

Here, when you set this attribute in any "Request/Response" that means you allow only that specific MIME type data in "Request/Response".

I have the basic understanding of HTTP Request/Response I hope this info will help you Please check and make sure you provided content related settings with appropriate MIME Type.

otherwise you can follow this link www.webdev.org