8

I'm designing an api that returns an image url that gets from a third party service.

My problem is that for all the media I'm using what I call a "media object"

    {
     "ContentType": "image/jpeg",
     "href": "http://..."
    }

But the third party service does not provide a content type, just a url.

Is the image/* ContentType valid?

I saw it mentioned in other questions like this and this, but I haven't seen it in any Standard like the rfc2045 and its not in the list of options in Wikipedia.

My intention is to prevent my server from having to load the image in order to get the real content type.

The reason I'm using the "media object" is because we can server videos in the same field and that information is very useful to play videos and to separate images form videos.

raaaay
  • 496
  • 7
  • 14
J-Rou
  • 2,216
  • 8
  • 32
  • 39

1 Answers1

4

Technically speaking, no.

image/* is only valid as a pattern for MIME types, not as a MIME type on its own. (For instance, in HTTP Accept headers, image/* can be used to accept any image file.) Since it sounds like you're making up your own protocol here, though, it's up to you whether this is allowable; just don't return it as a Content-Type for an object.

Anyways, you may also want to consider running a HEAD request on the URL and getting the real content type from that.

  • 2
    Thank you for confirming my thoughts. I was trying to prevent having to run the `HEAD request on the URL`. I might end up changing the ContentType field in the JSON to a MediaType or simply Type field that doesn't have the same name as the HTTP Content-Type and make my own protocol. I'll wait a little bit more before accepting the answer to see if someone else has more information. – J-Rou Jan 06 '15 at 01:29