SPM Prep – Add @protocol defining REST GET and POST methods#760
SPM Prep – Add @protocol defining REST GET and POST methods#760
@protocol defining REST GET and POST methods#760Conversation
| @@ -0,0 +1,15 @@ | |||
| @import Foundation; | |||
|
|
|||
| @protocol WordPressComRESTAPIInterfacing | |||
There was a problem hiding this comment.
Two notes on the naming:
- I used "REST" and "API", instead of "Rest" and "Api" because they are acronyms and it feels more correct to have them all uppercase (when not used as the first word of a method).
- I used "Interfacing" to align with Swift naming conventions. In that context, an object conforming to this protocol should "interface with the WordPress.com REST API" which is exactly what
WordPressComRestApidoes.
I'm a bit concerned by the ambiguity between "interfacing" as a verb and "interface" as a noun often used in programming languages to define something similar to an Objective-C or Swift protocol. Any suggestion for an alternative name is welcome.
| - (void)get:(NSString * _Nonnull)URLString | ||
| parameters:(NSDictionary<NSString *, NSObject *> * _Nullable)parameters | ||
| success:(void (^ _Nonnull)(id _Nonnull, NSHTTPURLResponse * _Nullable))success | ||
| failure:(void (^ _Nonnull)(NSError * _Nonnull, NSHTTPURLResponse * _Nullable))failure; | ||
|
|
||
| - (void)post:(NSString * _Nonnull)URLString |
There was a problem hiding this comment.
I decided not to uppercase GET and POST like elsewhere in the code because of the naming convention of starting methods names in lowercase.
Interestingly, even if uppercase, the conversion from Objective-C to Swift results in the word being lowercased in the generated Swift version.
There was a problem hiding this comment.
Also interesting, Xcode suggested the method signature. I think it's a new Xcode 15.2/15.3 feature? I was pleasantly surprised. Definitely saved me some time in figuring out the block signatures.
| 3FFCC0532BABC75F0051D229 /* Sources */ = { | ||
| isa = PBXGroup; | ||
| children = ( | ||
| 3FFCC0542BABC7680051D229 /* APIInterface */, | ||
| ); | ||
| path = Sources; | ||
| sourceTree = "<group>"; | ||
| }; | ||
| 3FFCC0542BABC7680051D229 /* APIInterface */ = { | ||
| isa = PBXGroup; | ||
| children = ( | ||
| 3FFCC0562BABC7D20051D229 /* include */, | ||
| ); | ||
| path = APIInterface; | ||
| sourceTree = "<group>"; | ||
| }; | ||
| 3FFCC0562BABC7D20051D229 /* include */ = { | ||
| isa = PBXGroup; | ||
| children = ( | ||
| 3FFCC0552BABC78B0051D229 /* WordPressComRESTAPIInterfacing.h */, | ||
| ); | ||
| path = include; | ||
| sourceTree = "<group>"; | ||
| }; |
There was a problem hiding this comment.
I took the chance of adding this new file to setup the Sources/ SPM structure.
After this lands, I'll make a dedicated PR that moves all the files in Sources/WordPressKit and a new Tests/WordPressKitTests.
Once that happens, I'll follow up with another PR that extracts WordPressComRestApi and the related types in something I'm tentatively naming "CoreAPI", as per #738
| * @brief The interface to the WordPress.com API to use for performing REST requests. | ||
| * This is meant to gradually replace `wordPressComRestApi`. | ||
| */ | ||
| @property (nonatomic, strong, readonly) id<WordPressComRESTAPIInterfacing> wordPressComRESTAPI; |
There was a problem hiding this comment.
The aim of this PR is to get feedback on the direction. As such, I haven't gone through the considerable effort of replacing all usages of the concrete WordPressComRestApi *wordPressComRestApi with the abstracted id<WordPressComRESTAPIInterfacing> wordPressComRESTAPI.
Assuming the direction I envisioned resonates, that'll be my next step.
| self = [super init]; | ||
| if (self) { | ||
| _wordPressComRestApi = wordPressComRestApi; | ||
| _wordPressComRESTAPI = wordPressComRestApi; |
There was a problem hiding this comment.
Once all the concrete WordPressComRestApi usages will have been replaced, this init will take an id<WordPressComRESTAPIInterfacing> input, effectively decoupling ServiceRemoteWordPressComREST (Objective-C) from WordPressComRestApi (Swift) via WordPressComRESTAPIInterfacing (Objective-C).
This is the model implemented in https://github.com/Automattic/spm-abstraction-layer-demo which should allow us to organize the code in a Swift package that Xcode can compile.
Use it in one call withing `AccountServiceRemoteREST`. The tests verify it works as expected.
Used for all POST requests in `AccountServiceRemoteREST`
The SPM-compatible folder structure was giving me trouble when trying to
validate the `podspec`.
At first, I thought it was simply because
`WordPressComRESTAPIInterfacing.h` was not in a path known to CocoaPods.
But even after updating the `podspec` to:
```diff
@@ -18,9 +18,10 @@ Pod::Spec.new do |s|
s.swift_version = '5.0'
s.source = { git: 'https://github.com/wordpress-mobile/WordPressKit-iOS.git', tag: s.version.to_s }
- s.source_files = 'WordPressKit/**/*.{h,m,swift}'
+
+ s.source_files = 'WordPressKit/**/*.{h,m,swift}', 'Sources/**/*.{h,m,swift}'
+ s.public_header_files = 'Sources/**/include/*.h', 'WordPressKit/**/.h', 'WordPressKit/WordPressKit.h'
s.private_header_files = 'WordPressKit/Private/*.h'
- s.header_dir = 'WordPressKit'
s.dependency 'NSObject-SafeExpectations', '~> 0.0.4'
s.dependency 'wpxmlrpc', '~> 0.10'
```
I still got errors:
```
- ERROR | xcodebuild: /var/folders/dq/cdqxvx3s5ps75564rpmb_dc00000gn/T/CocoaPods-Lint-20240321-63072-nntpgw-WordPressKit/DerivedData/App/Build/Products/Release-iphonesimulator/WordPressKit/WordPressKit.framework/Headers/WordPressKit.h:10:9: error: 'WordPressKit/ServiceRemoteWordPressComREST.h' file not found
```
In the proof of concept from
#738, the SPM
folder structure is compatible with CocoaPods. As such, I decided to
defer moving the files to when I can do it in one go.
779ec14 to
b65746d
Compare
This PR is meant to get early feedback on the design direction for the abstraction layer required for SPM support.
It:
WordPressComRESTAPIInterfacingWordPressComRestApiconform to the protocolI'm aware of the CocoaPods validation failure. Working on fixing it by updating the paths definitions in the
podspec.Testing Details
CI is enough.
Next up
Basically, cherry-pick the work from #738 but in a neat and reviewable order:
Bundlehelper that differentiates between SPM and CocoaPods installationsSee also, #756 and #758 which is related to the SPM work but independent from this one.
CHANGELOG.mdif necessary. — N.A.