A small data call in an older WebForms application does not require serializing the whole page. An ASMX WebMethod can expose a narrow lookup contract. The design work goes beyond adding an attribute: authentication, input, responses and errors need to remain separate from page presentation state.
Expose only the fields the caller needs
The context is the WebForms portal and data-helper structure in my archive. This integration example belongs to .NET Framework and System.Web, not to ASP.NET Core hosting. LookupReply contains only ID and title; the page control tree, ViewState and persistence entities stay outside the response.
using System.Web;
using System.Web.Services;
using System.Web.Script.Services;
using System.Security;
[ScriptService]
public class LookupService : WebService
{
[WebMethod]
[ScriptMethod(ResponseFormat=ResponseFormat.Json)]
public LookupReply GetItem(int id)
{
if(Context.User.Identity == null || !Context.User.Identity.IsAuthenticated)
throw new SecurityException("Authentication required");
if(id!=1) throw new ArgumentException("Unknown item");
return new LookupReply { Id=1, Title="Demo" };
}
}
public class LookupReply { public int Id {get;set;} public string Title {get;set;} }ScriptService marks the class for script-oriented service use, WebMethod exposes the operation, and ScriptMethod specifies the response-format expectation. An .asmx file pointing to the class and appropriate host configuration are still required. Compiling this class alone does not demonstrate a running endpoint.
Do not confuse ASMX methods with page methods
This class derives from WebService and represents an ASMX service. A static WebMethod exposed from an .aspx page through PageMethods is a different hosting arrangement. The request URL, invocation shape and available context depend on that choice. Treating every WebMethod attribute as the same endpoint model makes legacy integration failures harder to diagnose.
The JSON response may also include an ASP.NET d wrapper depending on the host and invocation. Inspect the real response instead of copying response.d handling into every client blindly. Receiving JSON does not by itself establish that the business operation succeeded.
Authenticate and authorize on the server
The example checks Context.User rather than relying on a visible button or client-side isAdmin value. The authentication module and service configuration must supply the intended identity. Session behavior is another explicit concern; a WebMethod should not be assumed to share all page-session behavior automatically.
After authentication comes resource authorization. The sample accepts only ID one. A real lookup must query within the caller's permitted scope, not assume that every authenticated user can read every ID. Database commands should use parameters; an integer coming from a URL is still submitted input.
Thrown exceptions are not a finished HTTP contract
SecurityException and ArgumentException make the rejection paths visible here. The ASMX host's translation into HTTP status and response body requires separate verification. The snippet should not be presented as automatically producing a modern structured 401 or 400 response. Production handling needs consistent mapping without disclosing internal stack traces.
If write operations are added, returning JSON does not create CSRF protection. Cookie-authenticated writes need server-side safeguards. Combining a lookup and a mutation in one GET call also creates undesirable caching and replay semantics.
Improve the boundary without rewriting everything
A narrow DTO and delegation into an application service can clarify a legacy endpoint incrementally. That also makes business behavior easier to retain when the transport is replaced later. Test anonymous calls, forbidden IDs, missing records and successful replies separately, then verify that deployment preserves the expected authentication module, endpoint path and JSON shape.