Add structured syntax suffix support to WAMimeType - #1546
Conversation
- Add isJson() method to check for JSON MIME types (supports RFC 6839 structured syntax) - Add subSeparatorIndex() private method to find '+' separator position - Add subName() method to extract subtype name before '+' - Add syntax() method to extract structured syntax suffix after '+' - Add comprehensive tests for all new methods covering edge cases
- Correct index values in testSubSeparatorIndex (8 instead of 14 and 13) - Use assert:equals: instead of assert:
marschall
left a comment
marschall
left a comment
There was a problem hiding this comment.
Not 100% sure about the selector names and semantics.
Formatting sometimes a bit different than rest of the code.
| @@ -0,0 +1,10 @@ | |||
| accessing | |||
| syntax | |||
| "Answers the structured syntax suffix identified by the final '+' in | |||
There was a problem hiding this comment.
Where does the word "syntax" come from? RFC-6838 uses the word "suffix". But in this case we should probably answer nil if it is missing.
There was a problem hiding this comment.
Thanks for the feedback. Can you be a bit specific about the formatting? Is there a list of rules?
The problem at hand is to determine whether or not the content type is one of the possible json content types. The names in the rfc and the names used for the parts in a more simple content type like 'application/json' are hard to abstract over.
This implementation depends on a selector that returns 'json' for both 'application/json' and 'application/hal+json'. In 'application/json' there is no suffix and in 'application/hal+json' the suffix is '+json' according to the rfc. A different selector named syntax is used to address this. Do you have a suggestion for an alternative name for this selector?
In 'application/json' there is no sub type name, and there for subName will return nil.
Alternatively, we could avoid abstractions and could do for 'application/json'
- sub --> 'json'
- subName/subPrefix --> nil
- syntax/suffix --> nil
and for 'application/hal+json' - sub --> 'hal+json'
- subName/subPrefix --> 'hal'
- syntax/suffix --> 'json'
and then implement isJson accordingly using or:.
Or avoid all naming and implement isJson as
self sub = 'json' or: [self sub endsWIthSubcollection: '+json']
What do you think?
| @@ -0,0 +1,10 @@ | |||
| accessing | |||
| subName | |||
There was a problem hiding this comment.
Would #subPrefix be preferable?
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1546 +/- ##
==========================================
+ Coverage 52.27% 52.33% +0.05%
==========================================
Files 9350 9357 +7
Lines 77775 77866 +91
==========================================
+ Hits 40657 40748 +91
Misses 37118 37118 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2 participants
Add support for structured syntax suffixes (e.g. application/hal+json and application/atom+xml) to WAMimeType.
Introduces:
and updates #isBinary to recognize JSON-based media types via their structured syntax suffix.
Examples: