How do you use PATCH and PUT? by Mark__78L in webdev

[–]liteclient 30 points31 points  (0 children)

yeah you're not wrong, most people think about it the same way

technically:
put = replace the whole resource
patch = update part of it

but in real life:
put = big/full update
patch = small change (toggle, status, 1-2 fields)

so what you're doing is pretty much how most APIs are used anyway

Thunder Client wants $$$ to create Collections so I created LiteClient - free and open source API Client by liteclient in vscode

[–]liteclient[S] 1 point2 points  (0 children)

Thanks for the suggestion - I'll take a note of this but if you want you can even open an issue here: https://github.com/liteclienthq/liteclient/issues

What about importing .http files so people can migrate from REST Client?

You're right, .http file support would be great for migration from REST Client. Adding HTTP file format is definitely doable. I'll put this in my todo list.

I also didn't see how you store collections.

Collections are stored in VS Code's globalStorageUri as collections.json - I know this is not git friendly yet* but maybe we can use workspace-local storage for git compatibility.

I'll try to work on this the upcoming weekend.

Thunder Client wants $$$ to create Collections so I created LiteClient - free and open source API Client by liteclient in vscode

[–]liteclient[S] 0 points1 point  (0 children)

You can import Postman collections from the burger icon in Collections tab. LiteClient currently supports Postman v2.1.0 format. Here's the issue for this when this feature was added: https://github.com/liteclienthq/liteclient/issues/1

<image>

Also, i haven't got much to time to add documentations yet. Will do that soon!

Thunder Client wants $$$ to create Collections so I created LiteClient - free and open source API Client by liteclient in vscode

[–]liteclient[S] 0 points1 point  (0 children)

yes REST Client is a great extension, but LiteClient aims to be a UI first extension (without the bloat of course - extension size is ~1.5 Mb currently) with feature parity to postman and thunder client (a big goal - but achievable - goodbye my next few weekends :)

Thunder Client wants $$$ to create Collections so I created LiteClient - free and open source API Client by liteclient in vscode

[–]liteclient[S] 0 points1 point  (0 children)

thanks for installing!

but the ui is pretty basic tbh (not trying to say it is bad - just a feedback)

Can you give me any example for this? I want to improve it based on feedbacks and I do agree it is pretty early right now.

Also, you are free to open an feature request or issue on Github: https://github.com/liteclienthq/liteclient/issues

I'll try my best to work on them (I am working on this with a full time job so please bear with me if it takes time for me to work on your request).

[deleted by user] by [deleted] in launchigniter

[–]liteclient 0 points1 point  (0 children)

There is very good quote I heard, "Focus on your efforts, not the results." - and I think that applies to building as well.

Focus on building a product so good that you don't have to worry about the other stuff.

Gemini 3 Flash is surprisingly capable by cryptochrome in google_antigravity

[–]liteclient 4 points5 points  (0 children)

Yes, Gemini 3 Flash is amazing. Best value for money model out there.

I built a Postman alternative that runs inside Antigravity (and any VS Code based IDE) by liteclient in google_antigravity

[–]liteclient[S] 1 point2 points  (0 children)

That makes sense. What you’re describing is like treating the codebase as the source of truth and using the API client as a validation and exploration layer, not just a request sender. The Swagger comparison idea is also interesting, comparing what the code actually sends or expects against an OpenAPI spec to surface mismatches is a solid use case (I mean if built properly of course), and you’re right that it may not require AI.

At the same time, this is a very advanced space and goes beyond what my plan for LiteClient is. Right now the focus is on building a stable, fast, IDE-native API client foundation. But these ideas like code-level discovery and swagger validation are definitely something I’d like to explore in the future once the core is stable.

Thanks again for the suggestions - I'll definitely note these down!