| Time |
S |
Nick |
Message |
| 00:00 |
|
fumanchu_ |
just one more place to get things out of sync. what do I do if I get 400 but status: OK? |
| 00:01 |
|
fumanchu_ |
but probably only worth changing if you haven't deployed yet |
| 00:01 |
|
whartung |
follow the code, the status (should be) just verbage |
| 00:02 |
|
pdurbin |
follow-the-code++ |
| 00:02 |
|
fumanchu_ |
whartung: I mean in pdurbin's payload, not the Reason-Phrase |
| 00:02 |
|
|
azr joined #rest |
| 00:02 |
|
whartung |
ah |
| 00:02 |
|
whartung |
"Don't do that" |
| 00:02 |
|
fumanchu_ |
yeah |
| 00:05 |
|
fumanchu_ |
and if the rule is "follow the code" then the status starts to look less and less useful. clients will need to internationalize based on the code rather than show any status message anyway. The exception to all of that is if the "status" value is actually part of the media type and conditions (to a machine client) how to interpret the rest of the payload format, in which case you really do have to think about what to do with 400 + status "OK |
| 00:06 |
|
pdurbin |
all of my asserts check the status code: https://github.com/IQSS/dataverse-apitester/blob/master/src/test/java/org/dataverse/apitester/sword/SwordTest.java |
| 00:07 |
|
fumanchu_ |
very good |
| 00:07 |
|
fumanchu_ |
who's writing the client(s) for your system? |
| 00:10 |
|
pdurbin |
here's one (OJS): http://projects.iq.harvard.edu/ojs-dvn/book/faq-ojs-dataverse-integration-project |
| 00:10 |
|
pdurbin |
and another: https://osf.io/getting-started/#dataverse |
| 00:16 |
|
fumanchu_ |
looks like fun :) |
| 00:17 |
|
pdurbin |
it is, actually :) |
| 00:18 |
|
pdurbin |
and that was with our old AtomPub based API. soon we'll have more APIs in production |
| 00:20 |
|
pdurbin |
the community has been good about telling us what they want API-wise |
| 00:25 |
|
|
shrink0r_ joined #rest |
| 01:06 |
|
|
shrink0r joined #rest |
| 01:10 |
|
|
shrink0r_ joined #rest |
| 01:24 |
|
|
azr joined #rest |
| 01:44 |
|
|
mezod joined #rest |
| 01:58 |
|
|
shrink0r joined #rest |
| 02:43 |
|
|
shrink0r_ joined #rest |
| 04:13 |
|
|
shrink0r joined #rest |
| 04:22 |
|
|
shrink0r_ joined #rest |
| 04:27 |
|
|
lemur joined #rest |
| 05:25 |
|
|
fumanchu joined #rest |
| 05:32 |
|
|
fumanchu_ joined #rest |
| 06:41 |
|
|
adaro joined #rest |
| 07:15 |
|
|
tr3online joined #rest |
| 08:16 |
|
|
adaro joined #rest |
| 08:35 |
|
|
Andre-B joined #rest |
| 08:38 |
|
|
azr joined #rest |
| 09:19 |
|
|
shrink0r joined #rest |
| 09:35 |
|
|
interop_madness joined #rest |
| 09:59 |
|
|
Left_Turn joined #rest |
| 10:33 |
|
|
vanHoesel joined #rest |
| 11:01 |
|
|
azr_ joined #rest |
| 12:05 |
|
|
mezod joined #rest |
| 12:18 |
|
|
tr3online joined #rest |
| 12:27 |
|
|
shrink0r_ joined #rest |
| 12:36 |
|
|
vanHoesel joined #rest |
| 12:49 |
|
|
composed joined #rest |
| 12:50 |
|
composed |
I wonder how is the ambiguity of "nulipotent" handled for get with it does mutate, say, server logs |
| 12:59 |
|
|
azr joined #rest |
| 13:13 |
|
|
azr joined #rest |
| 14:13 |
|
|
nkoza joined #rest |
| 14:39 |
|
|
azr joined #rest |
| 14:49 |
|
|
tr3online joined #rest |
| 15:02 |
|
|
vanHoesel joined #rest |
| 15:07 |
|
|
vanHoese_ joined #rest |
| 15:22 |
|
pdurbin |
Should my API return a "MIME Type" or a "Content Type"? For values like "image/png" I mean. |
| 15:25 |
|
saml |
pdurbin, Content-Type: image/png |
| 15:25 |
|
trygvis |
"media type" |
| 15:25 |
|
trygvis |
http://www.iana.org/assignments/media-types/media-types.xhtml |
| 15:27 |
|
trygvis |
but I think everybody will understand you if you way "mime type", "content type" or "media type" |
| 15:27 |
|
pdurbin |
ok |
| 15:28 |
|
pdurbin |
I think I might go with "content type" but yeah it's looking like "media type" might be the more modern term. MIME feels a little archaic. |
| 15:28 |
|
trygvis |
yes, MIME came from email so it's mainly used there |
| 15:29 |
|
pdurbin |
what term to people use for the "friendly" name? "file type"? |
| 15:29 |
|
trygvis |
not sure what you mean by "friendly name" |
| 15:29 |
|
pdurbin |
for example "PDF" instead of "application/PDF" |
| 15:29 |
|
pdurbin |
or maybe "Microsoft Word document" |
| 15:30 |
|
trygvis |
dunno, I guess it depends on how you treat the file |
| 15:30 |
|
|
vanHoesel joined #rest |
| 15:30 |
|
trygvis |
for .pdf and .doc they might be obvious, probably not for atom or collection+json documents |
| 15:31 |
|
pdurbin |
here's where we translate mime/content/media types to a "friendly" version: https://github.com/IQSS/dataverse/blob/master/src/main/java/MimeTypeDisplay.properties |
| 15:31 |
|
trygvis |
I work with attachments to invoices and stuff so I would probably go with "file type" |
| 15:31 |
|
pdurbin |
hmm, maybe "display" instead of "friendly" |
| 15:32 |
|
pdurbin |
meh, it's already this. seems fine: "file_type": "PNG Image" |
| 15:32 |
|
trygvis |
yeah, I think I would go with "file type" |
| 15:34 |
|
trygvis |
from the spec: Content-Type = media-type |
| 15:35 |
|
trygvis |
so I would say that "Content-Type describes the media type of the body" |
| 15:35 |
|
trygvis |
http://tools.ietf.org/html/rfc7231#section-3.1.1.5 |
| 15:35 |
|
trygvis |
similar for mail: http://tools.ietf.org/html/rfc4021#section-2.2.5 |
| 15:36 |
|
trygvis |
rfc4021 sticks to the existing mail nomenclature of "MIME" |
| 15:41 |
|
pdurbin |
trygvis: you seem to be saying you'd return "file_media_type": "image/png" (rather than file_content_type or file_mime_type) |
| 15:42 |
|
trygvis |
I'd return Content-Type in the http response :) |
| 15:43 |
|
fumanchu_ |
definitely |
| 15:43 |
|
fumanchu_ |
it'd be a real shame to have some resource B say resource A was "image/png" and then have it be a GIF when you actually GET it |
| 15:44 |
|
fumanchu_ |
leap before you look |
| 15:44 |
|
trygvis |
but if this is a link describing another resource I think I might have gone with "media-type" |
| 15:46 |
|
pdurbin |
I'm talking about what to return in the JSON payload of search results: http://guides.dataverse.org/en/latest/api/search.html |
| 15:46 |
|
pdurbin |
Search API: expose MIME Type of files · Issue #1595 · IQSS/dataverse - https://github.com/IQSS/dataverse/issues/1595 |
| 15:48 |
|
trygvis |
righto. I would possibly go with what http would use instead of inventing my own |
| 15:48 |
|
pdurbin |
trygvis: so "content type" |
| 15:48 |
|
trygvis |
so Content-Type, Content-Length instead of size_in_bytes etc |
| 15:49 |
|
pdurbin |
hmm, is content-length always in bytes? |
| 15:49 |
|
trygvis |
yes, think so |
| 15:50 |
|
trygvis |
http://tools.ietf.org/html/rfc7230#section-3.3.2 |
| 15:51 |
|
trygvis |
this is also useful: http://www.iana.org/assignments/message-headers/message-headers.xhtml |
| 15:51 |
|
trygvis |
your "type" field also kinda feels like a "rel" |
| 15:51 |
|
pdurbin |
yes, this is useful. I think I may stick with size_in_bytes though. |
| 15:51 |
|
trygvis |
this is an existing rel registry: http://www.iana.org/assignments/link-relations/link-relations.xhtml |
| 16:00 |
|
|
vanHoesel joined #rest |
| 16:24 |
|
|
vanHoesel joined #rest |
| 16:26 |
|
|
grazfather joined #rest |
| 16:28 |
|
grazfather |
Hey guys, if a POST request already has an object at that URI so it instead updates it, should it return 204? |
| 16:32 |
|
|
lemur joined #rest |
| 16:40 |
|
|
grazfather left #rest |
| 17:13 |
|
|
vanHoesel joined #rest |
| 17:18 |
|
|
azr joined #rest |
| 18:33 |
|
|
jackalista joined #rest |
| 18:39 |
|
|
tr3online joined #rest |
| 19:03 |
|
|
jackalista joined #rest |
| 19:46 |
|
|
Andre-B joined #rest |
| 19:56 |
|
|
shrink0r joined #rest |
| 20:01 |
|
|
Left_Turn joined #rest |
| 20:42 |
|
|
ralphschindler joined #rest |
| 20:52 |
|
|
ralphschindler joined #rest |
| 21:02 |
|
|
htowngangsta joined #rest |
| 21:51 |
|
|
ralphschindler joined #rest |
| 22:09 |
|
|
warehouse13 joined #rest |
| 22:26 |
|
|
azr joined #rest |
| 22:53 |
|
|
shrink0r joined #rest |
